Provides keyword and phrase search over Threads posts, returning matching posts with filters for recency, likes, and replies, plus options for match mode, only-new deduplication, and summary rows.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Threads Keyword Search MCP Server Find Threads posts about cold email from the last 30 days with 50+ likes"
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.
An MCP server for the Mamba Labs Threads Keyword Search actor on Apify. Search Threads for keywords and get one flat row per post that contains them.
Related MCP server: Enterprise Threads MCP Server
Each keyword is searched the way Threads search works for a visitor who is not logged in, which shows about 20 to 25 posts per search. By default a post is kept only when the keyword's words are in its text, next to each other and in order, so loosely related results are set aside and not charged. A post found by several keywords is returned once with every keyword it matched. Filters for age, likes, and replies, and an only new posts memory for schedules. Each keyword also returns one free summary row. No Threads or Instagram account, login, or key is used.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-threads-keyword-search": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-threads-keyword-search"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The search_threads_posts tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"Find Threads posts about cold email from the last 30 days."
"Which Threads posts mention our competitor by name this week?"
"Collect Threads posts about hubspot alternatives with their like counts."
search_threads_posts. One tool. Example arguments:
{
"keywords": [
"cold email",
"hubspot alternative"
],
"match_mode": "phrase",
"since_days": 30
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | no | Words or phrases to search Threads for, up to 50. |
| integer | no | Posts per keyword, up to 50 (Threads shows about 20 to 25). Default 25. |
| string | no | phrase, all_words, or off. Default phrase. |
| integer | no | Set aside posts older than this many days. |
| integer | no | Set aside posts with fewer likes. |
| boolean | no | Return matching replies too. Default true. |
| boolean | no | Skip posts an earlier run returned. Default false. |
| string | no | Name for the only new posts memory. |
| string | no | Optional cost cap for the run. |
| string | no | auto or residential. Default auto. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.0025 | $0.002375 | $0.00225 | $0.002125 |
| $0.0015 | $0.0015 | $0.0015 | $0.0015 |
Summary rows, refused input, posts set aside by your filters, and already delivered posts are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/threads-keyword-search
MIT. See LICENSE.
Search Threads for keywords and return one flat row per post that contains the keyword: text, author, publish date, likes, replies, reposts, quotes, and the post link, plus one free summary row per keyword. By default a post is kept only when the keyword's words are in its text next to each other; a post found by several keywords is returned once. Threads shows a visitor who is not logged in about 20 to 25 posts per search. Reads the public Threads search page; no login or key. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN and is billed per post row.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | Words or phrases to search Threads for, up to 50. | |
| only_new | No | Skip posts an earlier run returned (free). Default false. | |
| min_likes | No | Set aside posts with fewer likes. | |
| state_key | No | Optional name for the only new posts memory. | |
| match_mode | No | phrase keeps a post when the keyword's words are next to each other in its text; all_words when every word is somewhere; off keeps every result. Default phrase. | |
| proxy_mode | No | auto uses the Apify proxy pool with residential as the fallback; residential uses residential addresses for every search. Does not change the price. Default auto. | |
| since_days | No | Set aside posts older than this many days. | |
| max_charge_usd | No | Optional. The run stops before a charge that would pass this amount. | |
| include_replies | No | Return matching replies too. Default true. | |
| max_posts_per_keyword | No | Posts per keyword. Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, non-destructive; the description still adds substantial non-obvious behavior: the ~20-25 post ceiling per search, cross-keyword de-duplication, failure returned as an error with a run ID, APIFY_TOKEN requirement, and per-post-row billing. That is real context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and output shape, then constraints, then cost/auth, then error behavior — a sound ordering. It is a single dense paragraph of five sentences; every sentence carries information, though the packing makes it slightly harder to scan than a bulleted or clearly separated form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, zero-required tool with no output schema and no siblings, the description covers output shape, defaults, platform limits, auth, billing, and failure mode. Nothing an agent needs to decide or invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still contributes semantics the schema lacks, notably that a post matched by several keywords is returned once and that default matching is adjacency-based phrase matching. It does not elaborate on less obvious params like state_key or proxy_mode cost implications beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Threads for keywords') and immediately enumerates the exact output shape (one flat row per post with text, author, publish date, likes, replies, reposts, quotes, link, plus a summary row per keyword). An agent knows precisely what it gets back, not just what it calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the operating context: public Threads search page, no login or key required, ~20-25 posts per search as a visitor. It explains the default phrase-matching behavior and the de-duplication rule, which effectively tells the agent what to expect. There are no sibling tools to route against, but explicit 'when not to use' guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0search_threads_postsScored across 1 tool
Only one tool exists, so there is no possibility of confusing it with another tool. Its purpose—searching Threads posts by keyword—is clear and singular.
The single tool name follows a clear verb_resource_action pattern (search_threads_posts) and uses consistent snake_case. There are no conflicting conventions to compare against.
A single tool is slightly below the typical 3-15 range, but it fits the server's narrow, explicitly search-focused purpose. The tool is well-scoped and earns its place rather than being redundant.
The tool covers the core search operation with detailed post fields and a summary row, which is appropriate for a read-only keyword search server. Minor gaps include no pagination, date/author filters, or post-detail retrieval, but these are workable limitations for the stated scope.
Threads public posts, replies and profiles, with view counts, keyword and account search.
Search public Threads posts by keyword for AI agents: text, author, likes, replies, reposts.
Publish, reply, moderate, search and read insights on your Threads (threads.com) account.
Search and read public Reddit and X posts, comments, threads, profiles and Articles; run monitors.