Which integrations are available for this server?

Allows posting text and media to Bluesky and retrieving post analytics such as likes, reposts, replies, and quotes. Allows posting messages to Discord channels and retrieving reaction counts as analytics. Allows posting content to Instagram (requires approved Meta app) and retrieving post analytics. Allows posting text and media to Mastodon and retrieving post analytics such as favourites, boosts, and replies. Allows posting text and media to Reddit (as a post in a subreddit) and retrieving analytics like score, comments, and crossposts. Allows posting messages to Telegram channels or groups (no analytics available from Bot API). Allows posting content to Threads and retrieving post analytics such as views, likes, replies, reposts, and quotes. Allows posting content to TikTok (requires approved app) and retrieving post analytics. Allows posting content to YouTube (requires approved Google OAuth app) and retrieving post analytics.

How do I use postlayer-connect?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@postlayer-connect Post 'Hello from AI' to LinkedIn and X." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

postlayer-connect

by pokakrisztian2

Overview Schema Related Servers Score Discussions

TypeScript

Local

postlayer-connect

Let your AI post to your socials — an open MCP server for LinkedIn, X, Bluesky, Mastodon, Reddit, and more.

postlayer-connect is a local Model Context Protocol server. Point any MCP client at it — Claude Desktop, Claude Code, Cursor, ChatGPT desktop — connect your social accounts with your own app credentials, and your assistant can publish posts and read analytics for you.

Runs 100% locally. Your tokens never leave your machine.
Uses your developer apps and your accounts. No middleman API, no per-post fees.
Tokens are encrypted at rest (AES-256-GCM) in a local file.
MIT licensed. Fork it, audit it, extend it.

you: "post this to LinkedIn and X: shipping day. the open MCP social server is live 🚀"
AI:  ✅ posted to linkedin (id 7…)   ✅ posted to x (id 18…)

30-second quickstart

1. Add it to your MCP client. No install step — npx fetches and runs it.

Claude Desktop / Claude Code — add to your claude_desktop_config.json (or .mcp.json):

{
  "mcpServers": {
    "postlayer-connect": {
      "command": "npx",
      "args": ["-y", "postlayer-connect"],
      "env": {
        "LINKEDIN_CLIENT_ID": "your_id",
        "LINKEDIN_CLIENT_SECRET": "your_secret"
      }
    }
  }
}

Only add the credentials for the platforms you want. Bluesky and Nostr need none — you connect them with an app password / key. The server boots fine with an empty env and tells you what each platform needs.

2. Restart your client and ask it to connect an account:

"List the social platforms postlayer supports." "Connect my Bluesky — my handle is you.bsky.social and here's an app password."

3. Post:

"Post 'hello world from my AI' to Bluesky."

That's it.

Related MCP server: Outpost

Supported platforms

Works now — register your own app (a 5-minute, free, self-serve process), paste the keys, done. Bluesky and Nostr need no app at all.

Platform	Connect with	What you register	Post analytics you get back
LinkedIn	OAuth	LinkedIn app	likes, comments
X / Twitter	OAuth 1.0a	X developer app (Read+Write)	impressions, likes, reposts, quotes, bookmarks, clicks
Reddit	OAuth	Reddit app (type: web app)	score, comments, crossposts
Mastodon	OAuth	app on your instance (Preferences → Development)	favourites, boosts, replies
Bluesky	App password	nothing — Settings → App Passwords	likes, reposts, replies, quotes
Nostr	Private key (nsec)	nothing	— (no canonical analytics)
Discord	Bot token	Discord app → Bot	reaction count
Telegram	Bot token	@BotFather	— (Bot API exposes none)
Threads	OAuth	Meta / Threads app	views, likes, replies, reposts, quotes

Threads works for you + testers in dev mode. Scaling it to other people's accounts needs Meta App Review.

Needs your own approved app — the connector code is complete and correct, but these platforms only allow programmatic posting through a developer app that has passed their review. Get your app approved, flip one env flag, and it works.

Platform	Blocker	Flip when approved
Instagram	Meta App Review + Business Verification	`INSTAGRAM_APP_APPROVED=true`
TikTok	Content Posting API audit	`TIKTOK_APP_APPROVED=true`
YouTube	Google OAuth verification (sensitive scopes) + quota	`YOUTUBE_APP_APPROVED=true`

Until then these tools return an honest, specific "here's exactly what to submit" message — never a fake success.

The MCP tools

Tool	What it does
`list_platforms`	Every platform, its status, the credentials it needs, and the analytics it returns.
`connect_account`	Start a connect. OAuth platforms return a URL to open in your browser; credential platforms (Bluesky, Nostr, Discord, Telegram) take the fields inline.
`list_accounts`	Show your connected accounts and their ids.
`post`	Publish text + optional media (local file path or URL) to an account. Per-platform `settings` (e.g. Reddit `{subreddit, title}`).
`get_analytics`	Normalized analytics for one post. A metric that's missing means the platform doesn't expose it — never a faked zero.

Example prompts

"Post this to LinkedIn and X, and attach ~/Desktop/launch.png."
"Submit this as a text post to r/SideProject with the title 'I built an open MCP social server'."
"How did my last LinkedIn post do?" (feed it the post id post returned)
"Connect my Mastodon on mastodon.social."

How the OAuth connect works (local)

Because this server runs locally with no public URL, it starts a tiny loopback listener to catch the OAuth redirect.

Register http://localhost:8790/callback as an authorized redirect URL in each OAuth app you create.
Call connect_account → it returns an authorize URL.
Open it, approve, and the browser redirects back to the local listener, which exchanges the code and saves the account automatically.

Change the port with POSTLAYER_OAUTH_PORT (and POSTLAYER_OAUTH_HOST) if 8790 is taken — just register the matching URL.

Configuration

Set these in your MCP client's env block, or in a .env file in the working directory (auto-loaded). See .env.example for the full list.

Var	Purpose
`POSTLAYER_ENC_KEY`	Passphrase used to encrypt stored tokens (AES-256-GCM). Recommended. Generate with `openssl rand -base64 32`. If unset, a random key is generated once and saved (0600) in the data dir.
`POSTLAYER_DATA_DIR`	Where tokens + the key live. Default `~/.postlayer-connect`.
`POSTLAYER_OAUTH_PORT` / `POSTLAYER_OAUTH_HOST`	Local OAuth redirect listener. Default `localhost:8790`.
Per-platform app keys	e.g. `LINKEDIN_CLIENT_ID`, `X_API_KEY`, `REDDIT_CLIENT_ID`, … (see `.env.example`).

Where your tokens are stored

Connected-account tokens are written to ~/.postlayer-connect/tokens.json. The secret fields (access + refresh tokens, app passwords, signing keys) are encrypted at rest; the file is created 0600. Nothing is ever sent anywhere except directly to the platform's own API.

Run it yourself / develop

git clone https://github.com/<you>/postlayer-connect
cd postlayer-connect
npm install
npm run build
node dist/index.js   # boots on stdio, prints its status to stderr

Node 20+. The server speaks MCP over stdio, so run it through an MCP client rather than typing at it directly.

Want it fully managed + learning what works for you?

postlayer-connect is the open, run-it-yourself core. If you'd rather not manage apps and tokens — and want a system that schedules, approves, and learns which posts actually perform — that's Postlayer.

License

Available Tools

5 tools

connect_accountConnect an accountA

Connect one of your social accounts. For OAuth platforms (LinkedIn, X, Reddit, Mastodon, Threads) this returns a URL to open in your browser; after you approve, the account is saved automatically. For credential platforms (Bluesky, Nostr, Discord, Telegram) pass the required fields and it connects immediately. Call with just a platform to see which fields it needs.

ParametersJSON Schema

Name	Required	Description	Default
`fields`	No	For credential/key platforms: the field values (e.g. bluesky {identifier, password}; nostr {privateKey, relays}).
`platform`	Yes	Platform id, e.g. linkedin, x, bluesky, mastodon, reddit, nostr, discord, telegram, threads

TDQS

A4.6/5.0

Behavior4/5

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

Given no annotations, the description carries full burden. It discloses that OAuth returns a URL, credential connects immediately, and hints at dynamic field requirements. It does not mention side effects or permissions, but adequately describes the behavior.

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?

Three sentences, front-loaded with purpose, no wasted words. Well-structured to convey key information quickly.

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?

No output schema exists, but the description covers what to expect: URL for OAuth, immediate connection for credential. It addresses all aspects of tool usage given its complexity (2 params, nested object). Complete and self-contained.

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

Parameters5/5

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

Schema coverage is 100% and the description adds significant meaning beyond the schema: it explains the 'fields' parameter as an object with platform-specific examples (bluesky, nostr) and clarifies the 'platform' parameter. This helps the agent understand expected input.

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 clearly states the tool connects social accounts, distinguishes between OAuth and credential platforms, and explains the behavior. It uses specific verbs and resources, and is distinct from sibling tools like list_accounts and post.

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?

Provides explicit when-to-use guidance: connect an account. Explains how to use for OAuth vs credential platforms and advises calling with just a platform to see required fields. Lacks explicit when-not-to-use or alternatives, but the context is clear.

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

get_analyticsGet post analyticsA

Read normalized analytics for one published post. Returns the metrics the platform actually exposes (a missing metric means the platform does not provide it — never a fake zero). Target by account_id or platform, plus the post_id returned by post.

ParametersJSON Schema

Name	Required	Description
`post_id`	Yes	The platform post id returned by the `post` tool.
`platform`	No	Platform id — use instead of account_id when only one account of that platform is connected.
`account_id`	No	The connected account id (from list_accounts).

TDQS

A4.6/5.0

Behavior5/5

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

Discloses critical behavior: returns only metrics the platform provides, never fake zeros. No annotations exist, so description carries full burden and meets it.

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?

Two concise sentences covering purpose, behavior, and usage. No redundant information.

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?

No output schema but explains return semantics. Provides sibling context. Lacks details on error handling or pagination but adequate for a read tool.

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?

Adds context beyond schema: explains post_id origin, when to use platform vs account_id, and account_id source. Schema coverage is 100% but description enhances meaning.

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?

Clearly states verb 'read' and resource 'normalized analytics for one published post'. Distinct from sibling tools like 'post' and 'list_accounts'.

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?

Specifies targeting by account_id or platform with post_id from 'post' tool. Lacks explicit when-not-to-use but sufficient for typical use.

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

list_accountsList connected accountsA

List every social account you have connected, with its platform, handle, and account id (use the id in post / get_analytics).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. The term 'list' strongly implies a read-only, non-destructive operation. However, it does not explicitly confirm no side effects or mention authentication/rate limits, which would elevate transparency.

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?

Single sentence, front-loaded with action, efficiently conveys purpose, output, and usage hint. No unnecessary words.

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?

Completely covers the tool's purpose, output, and cross-reference to sibling tools. Given the tool's simplicity (0 parameters, no output schema), no additional information is needed.

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 tool has zero parameters and schema_description_coverage is 100% (trivially). With no parameters, the description adds value by listing output fields, which is appropriate. Baseline for 0 params is 4.

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?

Clearly states the action 'list', the resource 'social accounts you have connected', and specifies the output fields (platform, handle, account id). Distinguishes from siblings like connect_account (add) and post (create content).

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?

Provides usage guidance by telling the agent to use the account id from this tool in 'post / get_analytics'. Implicitly indicates when to use (before posting/analytics) but does not explicitly state when not to use or prerequisites.

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

list_platformsList platformsA

List every supported social platform, whether it works today or needs your own approved app, how you connect it, which credentials it needs, and what analytics it returns.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so the description carries full behavioral burden. It adequately describes what the tool returns (platform list with details) and implies a read-only operation. However, it does not explicitly mention rate limits, authentication needs, or safety.

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?

Single sentence that packs all relevant detail. It is front-loaded with 'List every supported social platform' and efficiently covers key aspects. Slightly wordy but clear.

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 simple tool with no parameters and no output schema, the description fully explains the purpose and output details (status, connection, credentials, analytics). It provides sufficient context for an agent to understand what to expect.

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?

No parameters, so schema coverage is 100%. Baseline is 4. The description does not need to add parameter information.

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 clearly states the tool lists every supported social platform with specific attributes (status, connection, credentials, analytics). It distinguishes itself from siblings like 'list_accounts' which likely lists user accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use or not use this tool versus alternatives. The use case is implied by the description, but there is no mention of preconditions or exclusions.

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

postPost to a connected accountA

Publish a post to a connected account. Give the text, optionally media (local file path or public URL), and any per-platform settings (e.g. reddit {subreddit, title}). Target the account by account_id, or by platform if only one account is connected.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The post body.
`media`	No	Attached media. Provide either path or url per item.
`platform`	No	Platform id — use instead of account_id when only one account of that platform is connected.
`settings`	No	Per-platform settings, e.g. reddit {subreddit:'test', title:'...'} or {url:'https://...'} for a link post.
`account_id`	No	The connected account id (from list_accounts).

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It states 'Publish a post' implying a write operation, but does not disclose aspects like whether the operation is synchronous, error handling, rate limits, or permissions needed. The minimal disclosure leaves the agent with uncertainties.

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 two sentences long, front-loading the core action and immediately following with optional parameters and targeting rules. Every word contributes meaning, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters (one required), no output schema, and no annotations, the description covers the basics of usage but lacks information about the return value or error scenarios. It is adequate for a standard tool but could be improved with a brief note on what the response looks like.

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% with well-described parameters. The description adds value by explaining how to use 'platform' versus 'account_id' and gives concrete examples for 'settings' (e.g., reddit {subreddit, title}), which goes beyond the schema's definition.

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 clearly states 'Publish a post to a connected account' with specific verb and resource. It also differentiates from sibling tools (connect_account, get_analytics, list_accounts, list_platforms) which are not posting tools. Additional details like media and per-platform settings further clarify scope.

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 description provides guidance on targeting an account by account_id or by platform when only one account is connected. It also gives an example of per-platform settings with reddit {subreddit, title}. However, it does not explicitly exclude scenarios or mention alternatives beyond the given options.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: account connection, account listing, platform listing, posting, and analytics. No overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., connect_account, list_accounts), with 'post' being a short but imperative verb, maintaining stylistic consistency.

Tool Count5/5

With 5 tools covering the core workflows of account connection, posting, and analytics, the count is well-scoped for the server's purpose—neither too few nor too many.

Completeness3/5

The tool surface covers essential operations but lacks tools for disconnecting accounts, deleting or editing posts, and listing published posts, which are notable gaps for a social media management server.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

qpost-mcp
io.github.arslan2012
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Social Media
1
socialclaw B
io.github.ndesv21
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
Social Media Marketing
32286
ClawLink
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181

Related MCP Servers

Social CLI MCP
Social Media Communication
alessio-web-dev
A
license
Not graded
quality
D
maintenance
MCP server for posting to Twitter/X, Reddit, LinkedIn, Instagram, and email via CLI or AI agents, with Telegram bot control and security confirmations.
Updated 5 months ago (2026-04-03 09:50 UTC)
7
MIT
Outpost
Social Media App Automation
andrezani
A
license
Not graded
quality
D
maintenance
Social media API and MCP server for AI agents that enables publishing to X, Instagram, LinkedIn, Reddit, Bluesky, and Threads from a single endpoint.
Updated 3 months ago (2026-06-05 19:39 UTC)
28
MIT
linkedin-mcp
Social Media Marketing
aneesh-a7
A
license
Not graded
quality
C
maintenance
A personal-use remote MCP server that lets you post to LinkedIn, queue/schedule drafts, and pull your own post analytics from Claude.
Updated 2 months ago (2026-07-01 12:43 UTC)
29
MIT
social0-mcp
Social Media Marketing
Abhishek-B-R
A
license
A
quality
B
maintenance
MCP server to manage social media accounts from AI assistants, enabling post creation, scheduling, publishing, and media uploads across multiple platforms.
Updated 18 days ago (2026-08-18 00:13 UTC)
13
193
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pokakrisztian2/postlayer-connect'

If you have feedback or need assistance with the MCP directory API, please join our Discord server