Schedule and manage Facebook posts including creating, updating, deleting, and viewing analytics.
Schedule and manage Instagram posts including creating, updating, deleting, and viewing analytics.
Schedule and manage Pinterest posts including creating, updating, deleting, and viewing analytics.
Schedule and manage TikTok posts including creating, updating, deleting, and viewing analytics.
Schedule and manage YouTube posts including creating, updating, deleting, and viewing analytics.
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., "@FastSocial MCP Server Schedule a post to Instagram for tomorrow at 9am saying 'Happy Monday!'"
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.
Schedule and manage social media posts across Facebook, Instagram, Twitter/X, LinkedIn, YouTube, TikTok, and Pinterest — directly from Claude.
Tool | Description |
| View account details, connected platforms, and plan info |
| Schedule a post to any connected platform |
| List posts filtered by status or platform |
| Get a single post by ID |
| Edit a post's text, scheduled time, or status |
| Delete a post |
| View post counts and platform breakdown |
| See all connected social accounts |
| List clients (for reseller accounts) |
| Browse the media library |
Related MCP server: @posteverywhere/mcp
Log in to fastsocial.ai
Go to Settings → API Keys
Create a new API key with the scopes you need:
posts:read — read posts
posts:write — create/edit/delete posts
analytics:read — view analytics
platforms:read — view connected platforms
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"fastsocial": {
"command": "npx",
"args": ["-y", "fastsocial-mcp-server"],
"env": {
"FASTSOCIAL_API_KEY": "fsk_your_api_key_here"
}
}
}
}git clone https://github.com/fastsocial/mcp-server
cd mcp-server
npm install
FASTSOCIAL_API_KEY=fsk_your_key npm start"Schedule a post to Instagram for tomorrow at 9am saying 'Happy Monday!'"
"Show me all my failed posts from last week"
"What's my post count breakdown by platform?"
"Update post abc123 to be scheduled for next Friday at noon"
"List all my draft posts"
All requests use your FastSocial API key passed as a Bearer token. Keys are scoped — a posts:read-only key cannot create or delete posts.
MIT
Delete a post by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Delete a post by its ID' without mentioning irreversible effects, authorization requirements, or error scenarios.
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?
Description is a single short sentence, no wasted words, but could be more informative without being verbose.
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 simple delete operation with full schema coverage and no output schema, the description is minimal but adequate. Lacks details on success/failure response or side effects.
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 description adds no extra meaning beyond what the input schema already provides for the 'id' parameter.
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?
Description clearly states the action ('Delete') and resource ('a post') with the key identifier (ID). It effectively distinguishes from siblings like update_post or get_post.
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?
No guidance on when to use this tool versus alternatives, no prerequisites, no exclusions. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current FastSocial account info including connected platforms, plan, and subscription status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It states the tool retrieves account info, implying a read operation, but does not disclose side effects, authentication requirements, or rate limits. The description is adequate but not comprehensive.
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?
The description is a single, clear sentence that efficiently conveys the tool's purpose. Every word adds value, and the key information is front-loaded.
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?
The description covers the essential purpose and output (account info with specific fields). However, it does not explain how this tool differs from closely related siblings like list_connected_platforms, and the lack of an output schema means return format is unspecified. Still, for a simple info tool, it is reasonably complete.
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?
There are no parameters, so schema coverage is 100%. According to scoring guidelines, 0 parameters yields a baseline of 4. The description adds no parameter info, which is acceptable given none exist.
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?
The description clearly states the tool retrieves current FastSocial account info, specifying included details like connected platforms, plan, and subscription status. It distinguishes from sibling tools such as list_connected_platforms (narrower scope) and get_analytics (different focus).
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 provides no guidance on when to use this tool versus alternatives like list_connected_platforms or get_analytics. Given the overlapping sibling tools, explicit usage context is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics summary for the account: total posts, breakdown by status, breakdown by platform, and posts created/published this month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read-only operation but does not explicitly state read-only, idempotent, or safety traits. With no annotations, this is a slight gap.
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?
The description is a single sentence that is clear and to the point with no unnecessary words. Every part adds information.
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?
Given no parameters and no output schema, the description covers the essential scope. It could benefit from mentioning the return format or that it aggregates data, but it is sufficient for a parameterless tool.
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% (no parameters exist), so baseline is 4. The description adds value by explaining what the analytics summary contains, going beyond an empty schema.
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?
The description clearly specifies the action ('Get analytics summary') and the components included (total posts, breakdowns by status and platform, monthly counts). It distinguishes from sibling tools like list_posts or get_account_info, which provide different data.
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 implies when to use this tool (to get an overview of analytics) without explicit alternatives or exclusions. While it lacks explicit usage guidance, the context is clear and no parameter decisions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific post by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as idempotency, authentication needs, rate limits, or error conditions. As a read operation, stating it is safe would help, but it is omitted.
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?
The description is a single sentence, highly concise and front-loaded. It is appropriately sized for a simple tool, though it could include a brief example or note without becoming verbose.
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 simple retrieval tool with one parameter, the description provides the minimum necessary information. However, it lacks details about the output (what 'details' means) and edge cases (e.g., missing post). This is adequate but not complete.
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% for the single parameter, and the schema already describes 'id' as 'The post ID'. The description adds no additional meaning beyond restating the parameter's role. Baseline score of 3 is appropriate.
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?
The description clearly states the action ('Get details') and the resource ('a specific post by its ID'). It is specific and unambiguous. However, it does not differentiate from sibling tools like list_posts, which also retrieve posts but in bulk.
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 provides no guidance on when to use this tool versus alternatives like list_posts or update_post. It only states the basic function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List clients (for reseller accounts). Returns all clients under the reseller, or just the current client for single-account keys.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional partial name search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and effectively discloses that the tool returns different results based on account type (reseller vs single-account) and supports an optional partial name search. No hidden behaviors are implied.
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?
The description is two sentences with no unnecessary words. It front-loads the main purpose and immediately specifies the scope. Every phrase adds value.
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?
Given the simple tool (one optional parameter, no output schema), the description adequately covers the two key behaviors (reseller vs single-account) and leaves no major gaps for an agent to understand what the tool does.
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?
The schema covers the only parameter with a description ('Optional partial name search'), and the description adds the context that it is for searching by partial name. Since schema coverage is 100%, baseline is 3; description adds minimal new semantic value.
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?
The description clearly states 'List clients (for reseller accounts)' and explains the distinction between reseller (returns all clients) and single-account keys (returns current client). This verb-resource pair is specific and distinguishes from sibling tools like list_posts or list_media.
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 clarifies when to use this tool: for listing clients under a reseller or for single-account keys. It does not explicitly mention when not to use it or name alternatives among siblings, but the context of 'clients' is clear and distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected social media platforms for this account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only listing operation but does not explicitly state that there are no side effects, rate limits, or account-specific constraints. Since no annotations are present, the description provides minimal behavioral transparency.
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?
The description is a single, efficient sentence that is front-loaded and contains no unnecessary words.
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?
The description adequately explains what the tool lists, but it could be improved by mentioning what attributes of each platform are returned. However, given the tool's simplicity, it is sufficiently complete.
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?
There are zero parameters, and the schema coverage is 100%. The description adds no parameter-specific information, which is acceptable given no parameters exist.
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?
The description clearly states the verb 'List' and the resource 'connected social media platforms for this account', making the tool's purpose unambiguous and distinguishing it from sibling tools like list_posts or list_clients.
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?
No guidance is provided on when to use this tool vs alternatives. For example, it does not clarify when to use this instead of get_account_info or list_media.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List uploaded media files in the media library.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Number of items to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. It only says 'list', but does not disclose whether authentication is required, ordering, pagination defaults, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, but slightly too minimal; a bit more detail could be added without harming conciseness.
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?
Given no output schema and no annotations, the description should explain the return format, pagination behavior, or ordering. It lacks these details, making it incomplete for a list tool with optional parameters.
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% with both parameters (page, limit) described in the schema. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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?
The description uses a specific verb ('list'), identifies the resource ('uploaded media files'), and specifies the location ('media library'). It clearly distinguishes from sibling tools like list_posts or list_clients, as no other tool lists media.
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 provides no guidance on when to use this tool versus alternatives (e.g., when to use list_media vs list_posts). There is no mention of prerequisites, filtering options, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scheduled, published, draft, or failed posts. Can filter by platform or status.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default 1) | |
| limit | No | Number of posts to return (default 20, max 100) | |
| status | No | Filter by post status | |
| platform | No | Filter by platform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'List' implies read-only, but no explicit disclosure of safety, auth needs, or side effects. Adequate for a simple listing tool.
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?
Two concise sentences front-loading the key action and filter capabilities, with no wasted words.
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 simple list tool with no output schema, the description covers the core functionality and filter options. Could mention pagination behavior, but schema covers page/limit params.
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% with detailed parameter descriptions. The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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?
The description clearly states 'List scheduled, published, draft, or failed posts' with a specific verb and resource, and distinguishes from sibling tools like get_post (single) and schedule_post.
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 implies filtering by platform/status but does not explicitly state when to use this tool versus alternatives like get_post for a single post, missing exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a social media post to be published at a specific time. Supports Facebook, Instagram, Twitter/X, LinkedIn, YouTube, TikTok, and Pinterest.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The post content/caption | |
| platform | Yes | Which social media platform to post to | |
| image_url | No | Optional public URL of an image to attach to the post | |
| scheduled_at | No | ISO 8601 datetime for when to publish (e.g. '2024-12-25T10:00:00Z'). Omit to save as draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as platform-specific constraints, rate limits, or authentication requirements. It only states basic functionality.
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?
The description is concise with two sentences, no redundant information, and the purpose is front-loaded. However, it could still be slightly more detailed without losing conciseness.
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?
With 4 parameters, no output schema, and no annotations, the description is adequate but incomplete. It does not explain return values, error conditions, or the draft-saving behavior (only implied by schema).
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?
The input schema has 100% coverage, so the description adds minimal additional meaning. It lists platforms but does not explain platform-specific nuances or formatting guidelines beyond the schema.
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?
The description clearly states the verb 'schedule' and the resource 'social media post', and lists supported platforms, distinguishing it from sibling tools like delete_post or get_post.
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 implies scheduling at a specific time but does not provide explicit guidance on when to use this tool versus alternatives like immediate posting or editing. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the text, scheduled time, or status of an existing post.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post ID to update | |
| text | No | New post content | |
| status | No | New post status (can only set to draft or scheduled) | |
| scheduled_at | No | New ISO 8601 scheduled datetime |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'update' implying mutation but omits details like whether the post must exist, if updates are irreversible, permission requirements, or how partial updates work. This is insufficient for a mutation tool.
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?
The description is a single, efficient sentence that directly states the tool's function with no filler. Every word earns its place.
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?
Given no output schema and 4 parameters, the description is adequate but minimal. It doesn't explain return values or side effects. For a moderately complex update operation, more context (e.g., what happens to unchanged fields) would be beneficial.
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?
The input schema has 100% coverage, so the baseline is 3. The description lists the updatable fields (text, scheduled time, status) which summarizes the parameters but adds no new constraints or usage details beyond the schema's descriptions.
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?
The description clearly states the verb (update) and the resource (post) with specific updatable fields (text, scheduled time, status). It distinguishes from sibling tools like delete_post or schedule_post by implying modification of existing posts, but could be more explicit about not creating new posts.
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?
No guidance is given on when to use this tool versus alternatives. For instance, it doesn't mention that schedule_post might be used for initial scheduling, or that update_post could revert a scheduled post to draft. The context is implied but not explicit.
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.0delete_postget_account_infoget_analyticsget_postlist_clientslist_connected_platformslist_medialist_postsschedule_postupdate_postScored across 10 tools
Each tool serves a distinct purpose: CRUD for posts, account info, analytics, media library, platforms, and clients. No overlap or ambiguity between tool functions.
All tool names follow a consistent verb_noun pattern (e.g., delete_post, get_account_info, list_media). No mixing of styles or inconsistent verbs.
10 tools cover the core domain of social media post management, account information, and analytics without unnecessary bloat. The number feels well-scoped for the server's purpose.
Full CRUD for posts, plus account, analytics, platforms, media listing, and client management. Missing media upload or platform connection/disconnection, but these are minor gaps for the primary use case.
Schedule and post to Instagram, TikTok, YouTube, X, Facebook, LinkedIn, Pinterest, Threads, Bluesky.
Schedule and publish social posts across 9 platforms (Instagram, LinkedIn, X, TikTok, Facebook, Threads, Pinterest, Bluesky, Mastodon) straight from Claude, ChatGPT, Cursor, or any MCP client. Create, edit, and reschedule posts, upload media, and pull account and post analytics, follower demographics, and best-time windows. 20 tools, free on every plan.
Schedule and publish posts to Instagram, TikTok, X, LinkedIn, YouTube, Pinterest, Facebook & more.
Schedule, publish, and analyze social posts on TikTok, Instagram, YouTube, X, Threads, LinkedIn.
