ghl-mcp-server-v2

Overview Schema Source Related Servers Discussions Admin

ghl_social_get_oauth_accounts

Read-onlyIdempotent

Retrieves available social media pages, channels, or locations after OAuth authentication so you can choose which account to connect.

Instructions

Get Available Accounts (Step 2 of 3)

OAuth Connection Flow - Step 2: Get Available Accounts

After completing OAuth authentication (Step 1), use this endpoint to retrieve the list of available pages, channels, or locations that can be connected.

OAuth Flow Position

Start OAuth → User authenticates, returns accountId
Get Accounts (this endpoint) → Lists available pages/channels to connect
Attach Account → Connect the selected account

What This Returns

The response varies by platform:

Platform	Returns
facebook	List of Facebook Pages the user manages
instagram	List of Instagram Professional Accounts (linked to Facebook Pages)
google	Google Business Profile locations
linkedin	LinkedIn Pages and Profile
tiktok	TikTok Creator account info
tiktok-business	TikTok Business Center accounts
youtube	YouTube Channels
pinterest	Pinterest Business accounts and boards
threads	Threads profiles

Next Step

From the response, select the account/page you want to connect and use its details in Step 3:

POST /social-media-posting/oauth/{locationId}/{platform}/accounts/{accountId}

Endpoint: GET /social-media-posting/oauth/{locationId}/{platform}/accounts/{accountId} (Version header: v3; source: v3/social-planner-v3.json) Requires a Sub-Account (location) token. OAuth scopes: socialplanner/oauth.readonly

Input Schema

Name	Required	Description
`search`	No	Search term to filter accounts/pages by name. Useful when the user has many pages to choose from.
`platform`	Yes	Social media platform. Must match the platform used in the preceding steps of the OAuth flow.
`accountId`	Yes	The OAuth Account ID received from Step 1 (Start OAuth) via the window message event
`locationId`	Yes	The Location ID where you want to connect this social account

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv2.1.0Nov 1, 2026

addedInput schema / properties / accountId / example
```
Added value: +"w37swmmLbA02zgqKPpxITe"
```

changedInput schema / properties / locationId / description

Previous value: -"Account Location Id"New value: +"The Location ID where you want to connect this social account"

addedInput schema / properties / locationId / example
```
Added value: +"w37swmmLbA02zgqKPpxITe2"
```

changedInput schema / properties / platform / description

Previous value: -"Social media platform"New value: +"Social media platform. Must match the platform used in the preceding steps of the OAuth flow."

changedInput schema / properties / platform / enum

Previous value: -[
-  "google",
-  "facebook",
-  "instagram",
-  "linkedin",
-  "tiktok",
-  "tiktok-business",
-  "youtube",
-  "pinterest",
-  "threads",
-  "bluesky"
-]New value: +[
+  "google",
+  "facebook",
+  "instagram",
+  "threads",
+  "bluesky",
+  "linkedin",
+  "tiktok",
+  "tiktok-business",
+  "youtube",
+  "pinterest"
+]

addedInput schema / properties / platform / example
```
Added value: +"facebook"
```
addedInput schema / properties / search / example
```
Added value: +"page name"
```

changedInput schema / required

Previous value: -[
-  "locationId",
-  "platform",
-  "accountId"
-]New value: +[
+  "platform",
+  "locationId",
+  "accountId"
+]

First observedv2.0.0Jul 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds the genuinely useful per-platform return-shape table (Pages vs. Locations vs. Channels vs. Boards) that no structured field provides. It also notes the sub-account token and the socialplanner/oauth.readonly scope, though it says nothing about pagination or error cases for a tool that can return long page lists.

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?

Front-loaded with title and step position, then ordered as flow → what it returns → next step. The markdown table is dense but earns its place by mapping platforms to return types; a few headers and the code block are slight overhead.

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?

With no output schema, the platform table is the right compensation and the sequencing plus return shape make the tool callable end-to-end. The main gap is that the optional `search` behavior and any paging/limits are undocumented.

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?

Schema coverage is 100%, so baseline is 3, but the description adds flow-level meaning: platform must correspond to the platform used earlier in the OAuth flow, and accountId originates from Step 1's returned value and feeds Step 3's URL. It does not mention the optional `search` filter, which is the parameter most likely to matter with many pages.

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 concrete verb and resource ('Get Available Accounts') and immediately scopes it as Step 2 of a three-step OAuth flow that lists pages/channels/locations available to connect. It explicitly distinguishes itself from the step-3 sibling that attaches the chosen account.

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?

Gives explicit preconditions ('After completing OAuth authentication (Step 1)') and an explicit next action with the exact endpoint to call in Step 3. An agent never has to guess whether to call this or the attach tool.

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

Deploy Server