Posting to Threads from Claude and ChatGPT: What You Actually Need to Know

How do you post to Threads from Claude and ChatGPT?

Posting to Threads from Claude is an MCP workflow that uses Meta OAuth, long-lived token refresh, and create-then-publish calls to draft, publish, or schedule Threads posts from an AI assistant.

Threads has moved from "interesting new app" to platform-you-have-to-be-on in the space of about eighteen months. Meta disclosed 150 million daily active users and ~450 million monthly actives in 2026, and TechCrunch reported in January that Threads has overtaken X in daily mobile DAUs. For anyone doing short-form text content, it is now a first-class surface.

Which means: if you use an AI assistant to draft posts, you want to be able to publish to Threads from the assistant. That is what a Threads MCP server does. This post is what the Threads API actually makes hard, what Model Context Protocol standardizes away, and what to verify before you rely on a server. For the protocol layer across LinkedIn, X, and Threads, see the MCP for social media reference.

What Threads API quirks does MCP need to handle?

Meta's Threads API is newer and a bit different from the Graph and Marketing APIs Meta veterans may recognize. The official docs that matter:

• Threads API Get Started
• Access tokens and permissions
• Long-Lived Access Tokens

Three things trip people up:

1. Short-lived tokens must be exchanged. The first token you get from the OAuth flow is short-lived. You have to exchange it for a long-lived token. Per Meta's docs, long-lived tokens are valid for 60 days, and you can refresh them by calling refresh_access_token at least one day after issuance but before expiry. Forget this step and your integration breaks after an hour.

2. The OAuth URL uses app_id, not client_id. Most OAuth 2.0 tutorials assume client_id. Threads uses app_id. Small copy-paste error; large percentage of first-time integrations that fail on step one.

3. Separate developer setup. You need a Meta developer account, a registered app, and approval for the threads_basic, threads_content_publish, and related scopes. For a founder who just wants to post, this is disproportionate friction.

A well-built MCP server does all three of those transparently. The question when evaluating one is whether the specific server you are considering does them correctly.

What does MCP actually standardize for Threads?

Model Context Protocol itself does not know anything about Threads. What MCP standardizes is:

• Tool discovery. Claude or ChatGPT can list available tools (create_post, publish_post, connect_platform) without knowing the server implementation.
• Authorization. MCP's authorization spec requires OAuth 2.1 with PKCE for the connection between the AI client and the MCP server. Your Threads token itself lives inside the MCP server, which uses it on your behalf when calling Meta's API.
• Response structure. Servers can return typed content (text, media, structured data), so clients can render something more useful than a plain string.

That is the boundary. MCP is not a Threads SDK. A Threads MCP server still has to implement the Threads OAuth dance, the long-lived token exchange, the refresh logic, and the specific content-publishing endpoints correctly. MCP just gives it a standard front door.

How do you set up Threads posting from Claude or ChatGPT?

For Claude Code, the MCP server is registered with a config block like:

{
  "mcpServers": {
    "feedsquad": {
      "type": "http",
      "url": "https://feedsquad.com/api/mcp"
    }
  }
}

For ChatGPT, MCP-capable servers are added through the tool settings. Once the server is registered, the flow is:

1. First tool call triggers an OAuth redirect so the MCP server can authenticate you (the user who will later own Threads tokens).
2. A connect_platform tool call kicks off the Threads OAuth flow — a second redirect where you grant the server permission to post on your behalf. The server handles the short-lived → long-lived token exchange automatically.
3. create_post builds a draft. Good servers run content checks here (length, banned phrases, AI-tell patterns).
4. publish_post hits Meta's API with your stored token and returns a structured result.

If the server is also cross-platform, you can describe what you want once and get adapted drafts for LinkedIn and X at the same time — not identical text, but platform-native versions of the same idea.

What should you verify before you rely on a Threads MCP server?

A short list I would actually run through for any Threads MCP server:

• Does the onboarding redirect you through Meta's OAuth flow? If it asks you to paste a long-lived token into a form, the server is not doing the token exchange and will break in 60 days.
• Does it document token refresh behavior? Refresh-on-demand is fragile; a good server refreshes proactively before the 60-day window closes.
• Does it return structured responses? A plain-text response is usable but limits what Claude or ChatGPT can render. Structured responses enable preview cards and inline editing.
• Does it handle the Threads content-publishing two-step? Threads publishing is a create-container-then-publish flow, not a single POST. An MCP server that returns "posted!" after just a create call is hiding a bug.
• What happens when Meta rate-limits you? A silent failure is worse than a loud one. The server should surface the rate-limit status back to your assistant so you can reschedule, not just eat the error.

The same diligence applies when you compare the best MCP servers for social media, because the protocol wrapper does not prove the platform implementation is correct.

What can you do from the conversation?

With a working setup, the actual surface area is broad. Typical tool calls:

• create_post — drafts with optional content checks.
• publish_post — publishes now.
• schedule_post — publishes at a future time (server-side scheduler, not a client-side cron).
• get_calendar — lists scheduled and draft content.
• connect_platform — initiates OAuth for a new account.

Anything beyond that — campaign generation, voice matching, analytics — is server-specific, not MCP itself. Treat it as "what does this particular server layer on top" rather than "what does MCP give me."

How should Threads posts be adapted across platforms?

The temptation with any cross-platform publishing tool is to write once and post everywhere. Threads punishes this specifically. The platform's short-post, conversational register is very different from LinkedIn's long-form and different again from X's headline-driven. Good cross-platform servers ask the model to adapt rather than copy — same core idea, platform-native register.

If you want a short take on how to do that adaptation by hand, I wrote it up in the LinkedIn to Threads strategy. The companion setup for X is posting to X from Claude.

Sources:

• Meta — Threads API Get Started
• Meta — Threads Long-Lived Access Tokens
• Meta — Threads Access Tokens and Permissions
• modelcontextprotocol.io — Authorization (OAuth 2.1)
• Social Media Today — Threads Reaches 150M Daily Active Users
• Backlinko — Number of Threads Users in 2026
• TechCrunch — Threads edges out X in daily mobile users

What should you know about posting to Threads from Claude?

Can Claude post to Threads? Claude can post to Threads when it is connected to an MCP server that handles Meta OAuth, per-user Threads tokens, and the create-then-publish API flow. Claude sends the request to the MCP server, and the server calls Meta's API.

Do I need a Meta developer account? A managed MCP server removes the Meta developer account requirement because it owns the Meta app and OAuth flow. Self-hosting puts the Meta app registration, permissions, and token storage on you.

Can I post images through a Threads MCP server? Image posting requires the media-container step in Threads' API, so the server must implement media upload and publish calls correctly. Many early Threads MCP servers are text-only. Check media support before planning image-heavy Threads campaigns.

Does MCP handle Threads token refresh itself? Token refresh sits inside the server rather than the MCP spec. The server has to exchange the short-lived token, store the long-lived token, and refresh it before the 60-day window closes.

What can go wrong with a Threads MCP server? The common failure points are expired tokens, missing media-container support, rate limits, and servers that treat container creation as a finished publish. Those are server implementation bugs. A good server surfaces the error back to Claude or ChatGPT instead of returning a fake success.

---

If you want a managed Threads MCP server that already handles the long-lived token exchange and the create-then-publish two-step, FeedSquad's MCP server does it across LinkedIn, X, and Threads in one integration. Free tier available.