threads-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_READ_ONLY | No | Set to '1' to refuse anything that changes state. | |
| THREADS_USER_ID | No | Your numeric Threads user ID. Optional; defaults the user_id argument. Use threads_get_profile with user_id 'me' to discover it. | |
| MCP_NO_DESTRUCTIVE | No | Set to '1' to allow posting but refuse deletes. | |
| THREADS_ACCESS_TOKEN | Yes | Your long-lived token for the Meta Threads API. Used in the Authorization: Bearer header. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| threads_get_profileC | A Threads profile. Pass user_id='me' for the authenticated account, which is also how you find your own numeric id. |
| threads_create_postA | Publish to Threads. This is immediately public and there is no draft state — the only undo is threads_delete_post, and everyone who saw it still saw it. An image is fetched by Threads from the URL you give, server-side, so it must be a publicly reachable http(s) URL. A local file path cannot work here. |
| threads_get_my_postsC | Your recent posts with their permalinks. Worth calling after publishing: it is how you confirm what actually went out rather than assuming the two-step container-and- publish sequence succeeded. |
| threads_get_post_insightsC | Engagement on one of your posts: views, likes, replies, reposts, quotes. |
| threads_delete_postA | Delete one of your own posts. Irreversible. |
| threads_callA | Call any Threads Graph API endpoint directly, for anything the tools above do not cover. Meta publishes no machine-readable spec for Threads, so this server does not claim a complete catalogue — this passthrough is how you reach the rest of the API without waiting for a tool to be written for it. Paths are relative to https://graph.threads.net/v1.0. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct operation: profile retrieval, post creation, listing posts, insights, deletion, and a generic passthrough. The generic 'call' tool is clearly scoped as a fallback for endpoints not covered, so there is no meaningful overlap or confusion.
All tool names follow a consistent 'threads_verb_noun' pattern, such as threads_get_profile, threads_create_post, and threads_delete_post. The naming is uniform, descriptive, and predictable across the set.
With six tools, the server covers the core Threads operations without being bloated. This is a well-scoped number for the apparent domain and leaves room for the generic passthrough to handle edge cases.
The tool set covers the essential profile, post creation/deletion, listing, and insights workflows. The inclusion of a generic call tool ensures that any missing or future Threads API endpoints remain accessible, so there are no dead ends.