What can you do with this server?

Summary: This MCP server lets you publish to and read from Threads through 5 exposed tools — it offers a subset (5 of 16) of the tools described in the README. * Publish a new text post to Threads (post_to_threads, max 500 characters) * Reply to an existing thread/post by its ID (reply_to_thread) * Fetch your recent Threads posts, with an optional count limit (default 10) (get_my_threads) * View your own profile info — username, bio, follower count (get_my_profile) * View insights for a specific thread — views, likes, replies (get_thread_insights) Not available in this schema (documented in the README but absent here): media/carousel posting, container publishing, quoting, reposting, deleting threads, reading replies, hiding replies, mentions, keyword search, account stats, and token checks.

Which integrations are available for this server?

Allows posting text threads, replying to threads, fetching recent threads, retrieving profile info, and getting thread insights (views, likes, replies, reposts, quotes) via the official Threads API.

How do I use threads-growth-mcp?

1. Click on "Deploy 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., "@threads-growth-mcp post a thread about my new blog post" 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.

threads-growth-mcp

by my5757980

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

threads-growth-mcp

Custom MCP (Model Context Protocol) server for Threads (Meta). It posts, replies, quotes, reposts, searches, manages replies and reads insights through the official, free Threads API.

Published on npm: @mj4384963/threads-growth-mcp

16 Tools

Tool	What it does	Permission
`post_to_threads`	Publish a text thread, optionally with a topic tag or link card	`threads_content_publish`
`post_with_media`	Publish an image or video post, or a carousel of 2-20, from public URLs	`threads_content_publish`
`publish_container`	Publish a video that was still processing when `post_with_media` returned	`threads_content_publish`
`reply_to_thread`	Reply to a thread or reply	`threads_content_publish`; for someone else's thread also `threads_keyword_search` or `threads_manage_mentions`
`quote_thread`	Quote a thread with your own text	`threads_content_publish`
`repost_thread`	Repost a thread to your profile	`threads_content_publish`
`delete_thread`	Delete your own thread or reply	`threads_delete`
`get_my_threads`	Fetch your recent threads	`threads_basic`
`get_replies`	Read a thread's replies, top-level only or the whole conversation	`threads_read_replies`
`hide_reply`	Hide or unhide a reply to your thread	`threads_manage_replies`
`get_mentions`	Posts where people @mentioned you	`threads_manage_mentions`
`search_threads`	Keyword or topic-tag search, top or recent	`threads_keyword_search`
`get_my_profile`	Username, name, bio, verified badge and follower count	`threads_basic`, `threads_manage_insights`
`get_my_stats`	Account totals for the last N days (profile views, likes, replies, reposts, quotes, link clicks), followers now, and an optional country/city/age/gender breakdown	`threads_manage_insights`
`get_thread_insights`	Views, likes, replies, reposts, quotes for one thread	`threads_manage_insights`
`check_token`	Whether the token is valid, when it expires, which permissions it has, and the last 24 hours' post/reply/delete quota. It never prints the token	`threads_basic`

What the API allows

Follow: the official API has no follow or discover endpoints for people.
Replying to others: under your own threads, replies always work. Replying to someone else's thread needs threads_keyword_search or threads_manage_mentions. Meta lets an app reply to, quote and repost public posts it has recently found through search, so find them with search_threads or get_mentions first.
Search: until Meta approves your app for threads_keyword_search, it only searches your own posts.
Mentions: until your app has advanced access to threads_manage_mentions, it shows only mentions by your app's testers.
Media: Threads downloads images and videos itself, so they must be public http(s) URLs.
- Images: JPEG/PNG, up to 8 MB.
- Videos: MP4/MOV, up to 5 minutes.
- A video can take a few minutes to process. post_with_media waits up to 45 seconds, then gives you a container ID for publish_container.
Limits:
- 250 posts a day (a carousel counts as one)
- 1,000 replies a day
- 100 deletes a day
- 2,200 searches a day
- check_token shows how much of the post, reply and delete quotas is used.
Follower breakdown: needs at least 100 followers.

Related MCP server: meta-threads-mcp

Setup (one time)

1. Create a Meta Developer App

Go to developers.facebook.com/apps/creation.
Add the use case "Access the Threads API".
Add every permission the tools use:
- threads_basic
- threads_content_publish
- threads_read_replies
- threads_manage_replies
- threads_manage_insights
- threads_keyword_search
- threads_manage_mentions
- threads_delete

2. Generate an access token

In your app, open Use cases → Access the Threads API → Settings.
Set a Redirect Callback URL, for example http://localhost:8915/callback.
Use the User Token Generator at the bottom of Settings:
1. Click "Generate Access Token" next to your Threads Tester account.
2. Approve every permission on the consent screen.
3. Copy the token.
The token lasts 60 days. check_token shows the expiry date. After it expires, generate a new one the same way.

3. Connect to Claude Code

npm i -g @mj4384963/threads-growth-mcp
claude mcp add threads-growth -s user \
  -e THREADS_ACCESS_TOKEN=your_token \
  -e THREADS_USER_ID=your_threads_user_id \
  -- node "$(npm root -g)/@mj4384963/threads-growth-mcp/index.js"

-- npx -y @mj4384963/threads-growth-mcp@latest works too. The catch: npx asks npm for the latest version on every start, and on a slow network that can exceed Claude Code's MCP connect timeout. After a new release, run npm i -g @mj4384963/threads-growth-mcp@latest to update the installed copy.

Tests

npm test

Every tool is tested against a fake fetch, which checks each request's path and parameters against Meta's docs. The tests also cover container polling on a fake clock, and the server over stdio. Nothing is sent to Threads.

Stack

Node.js 18+ (ES modules)
@modelcontextprotocol/sdk, stdio transport
Threads Graph API (graph.threads.net/v1.0)

Built by Muhammad Yaseen · Threads @ms5373268 · X @MuhammadYa5968

Available Tools

5 tools

get_my_profileA

Apni Threads profile info dekho (username, bio, followers)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only indicates a read operation ('dekho') and lists a few fields, but lacks details on behavior such as authentication needs, rate limits, or whether the return is static or real-time.

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 a single concise sentence that front-loads the purpose and includes key field examples. Every word earns its place; no redundancy.

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?

The tool is simple (no parameters, no output schema), but the description only mentions three fields (username, bio, followers) without indicating if other profile data is available. Given no output schema, the agent lacks full understanding of return structure. Adequate but incomplete.

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 input schema has zero parameters, and schema description coverage is 100% (nothing to cover). Per the baseline rule for 0 parameters, the score is 4. The description adds no parameter info because none exists.

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 action ('dekho' meaning 'see') and the resource ('your Threads profile info') with specific examples (username, bio, followers). It unambiguously distinguishes from sibling tools like get_my_threads.

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?

The description implies usage for viewing one's own profile but does not explicitly state when to use it versus alternatives or mention any prerequisites. The context from sibling tool names provides some guidance, but the description itself lacks explicit usage direction.

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

get_my_threadsB

Apne recent Threads posts dekho

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Kitne posts (default 10)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It implies a read-only operation via 'dekho' but lacks explicit statements about idempotency, authentication requirements, rate limits, or side effects. The agent gets minimal behavioral context.

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 extremely concise with a single sentence, no redundant words, and front-loaded information. Every word contributes to understanding, making it efficient for quick parsing.

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

Completeness2/5

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

Given no output schema, the description should explain what the tool returns (e.g., list of posts, fields, ordering). It does not, leaving a significant gap. Combined with the lack of annotations and limited parameter description, the tool definition is incomplete for reliable agent use.

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 coverage is 100% with the 'limit' parameter described as 'Kitne posts (default 10)'. The description adds no additional meaning beyond the schema, such as formatting constraints, range limits, or interplay with other parameters, so baseline score is appropriate.

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's action: viewing recent Threads posts. The verb 'dekho' (view) and resource 'Threads posts' are specific, and the tool is easily distinguished from siblings like 'post_to_threads' (write) and 'get_thread_insights' (analytics).

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparative scenarios with sibling tools, leaving the agent to infer usage purely from the name and description.

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

get_thread_insightsA

Kisi thread ke insights dekho (views, likes, replies)

ParametersJSON Schema

Name	Required	Description	Default
`thread_id`	Yes	Thread ID jiske insights chahiye

TDQS

A3.5/5.0

Behavior2/5

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

The description does not disclose behavioral traits beyond the basic action. It omits whether the operation is read-only, requires authentication, or how it handles errors. Since no annotations are provided, the description carries the full burden, which it does not fulfill.

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 extremely concise—a single sentence with a parenthetical. It front-loads the purpose with no filler words. Every part is essential and informative.

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?

For a simple tool with one parameter and no output schema, the description provides the necessary output details but lacks usage context, error handling, or any additional behavioral notes. It is minimally adequate but has clear gaps in completeness.

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 input schema only describes the 'thread_id' parameter. The description adds value by specifying that the returned insights include views, likes, and replies, which is not present in the schema. This clarifies the tool's output beyond the input parameter.

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 retrieves insights (views, likes, replies) for a thread. The verb 'dekho' (see) and the parenthetical listing of metrics specify the action and resource, distinguishing it from sibling tools that manage profiles, threads, or posts.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions under which this tool should be preferred. The sibling tools are not referenced in the description.

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

post_to_threadsB

Threads pe naya text post publish karo

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Post ka content (max 500 characters)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action (publish) without detailing side effects, authentication needs, or idempotency, leaving significant gaps.

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?

The description is a single concise sentence. While it could include more detail, it is appropriately sized for a simple tool with one parameter.

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

Completeness2/5

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

Given the absence of annotations and output schema, the description is incomplete. It lacks usage guidelines, behavioral details, and return value information, despite the tool's simplicity.

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 description does not add meaning beyond what the schema already provides (e.g., 'content max 500 characters'). Baseline 3 is appropriate.

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 verb 'publish' and the resource 'new text post on Threads', distinguishing it from sibling tools like get_my_threads (view) and reply_to_thread (reply).

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?

The description implies usage for creating new posts, but provides no explicit guidance on when to use this tool instead of alternatives, nor does it mention any prerequisites or exclusions.

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

reply_to_threadC

Kisi thread/post ka reply karo

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Reply ka content
`thread_id`	Yes	Jis post ka reply karna hai uska ID

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are present, and the description fails to disclose behavioral traits such as idempotency, required permissions, or side effects. It simply states 'reply' without elaboration.

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?

The description is a single, concise sentence with no unnecessary words. However, it lacks any structural formatting (e.g., bullets) that might improve readability.

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

Completeness2/5

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

Given the tool's simplicity, the description is minimally adequate but omits important context such as return value, thread/post distinction, or authentication requirements.

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%, so the schema already defines parameter meanings. The description adds no additional semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: replying to a thread/post. However, it does not differentiate from siblings like 'post_to_threads' which may also involve posting to threads.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites or scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Jul 9, 2026
- First observedget_my_profile
- First observedget_my_threads
- First observedget_thread_insights
- First observedpost_to_threads
- First observedreply_to_thread

Deploy Server

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

TDQS

A3.6/5.0

Scored 2026-07-09 07:20 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: profile viewing, listing posts, insights retrieval, posting, and replying. No functional overlap.

Naming Consistency5/5

All tools use a consistent verb_noun pattern with underscores (get_my_profile, get_my_threads, get_thread_insights, post_to_threads, reply_to_thread).

Tool Count5/5

5 tools is well-scoped for a Threads growth server, covering essential read/write operations without bloat.

Completeness4/5

Covers core functionality (read profile, list posts, get insights, post, reply). Minor gaps like deleting posts or viewing other users are acceptable for a focused growth server.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MysocialOAuth
io.mysocial
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
Social Media
1
Mastodon A
io.github.pipeworx-io
Mastodon MCP — public Mastodon data via mastodon.social (no auth required)
Social Media Search Communication
2
TwitterAPIsOAuth
io.github.TwitterAPIs
Official MCP server for twitterapis.com. Read and write Twitter/X: search, users, tweets, DMs.
Social Media Communication Search
1
qpost-mcp
io.github.arslan2012
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Social Media
1

Related MCP Servers

Threads MCP Server
Social Media Developer Tools
poisonstefani-dev
A
license
Not graded
quality
D
maintenance
A stdio MCP server for the official Threads API, enabling publishing, reading, moderation, insights, discovery, locations, and setup diagnostics.
Updated 5 months ago (2026-05-04 21:37 UTC)
2
MIT
meta-threads-mcp
Social Media Communication
MetaThreads
A
license
A
quality
C
maintenance
Unofficial MCP server for Meta's Threads API. Enables LLMs like Claude to publish posts, manage replies, and track insights through the Model Context Protocol.
Updated 9 months ago (2026-01-12 10:43 UTC)
15
MIT
threads-mcp
Social Media
griffinwork40
F
license
A
quality
D
maintenance
MCP server for the Threads API, enabling profile management, content reading, publishing, replies, and discovery through 26 tools.
Updated 4 months ago (2026-06-10 14:50 UTC)
26
-
threads-mcp
Social Media Browser Automation
bintangtimurlangit
A
license
A
quality
A
maintenance
An MCP server for Meta's Threads that acts as your own account, enabling reading profiles, posts, replies, timeline, search, and performing actions like posting, replying, liking, following, and scheduling, using a real logged-in browser session.
Updated 23 days ago (2026-09-14 01:45 UTC)
24
28 npm
1
MIT