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

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

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.

The Threads API Has Real Quirks

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 MCP Actually Standardizes 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.

The Realistic Setup, from Scratch

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 to Verify Before You Rely on a 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.

What You Can 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."

A Note on Cross-Platform Adaptation

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 How to Adapt LinkedIn Content for Threads.

FAQ

Do I need a Meta developer account? If you use a managed MCP server, no — the server is the Meta app. If you self-host an open-source Threads MCP server, yes, and you own the OAuth setup.

Can I post images? Images require the media-container step in Threads' API and depend on the server implementing it. Many early Threads MCP servers are text-only. Check before assuming.

What about Threads' content moderation? Publishing goes through the official API, so Meta's content policies apply exactly as they would for a native Threads post.

Will my tokens expire? Long-lived tokens last 60 days. A server doing its job refreshes proactively. If a refresh fails (e.g., you revoked access), you will be re-prompted through OAuth.

---

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.

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