Manage Postbase social scheduling—list channels, create/schedule posts, schedule X threads, view scheduled posts, and cancel them.
list_channels: List social channels connected to your Postbase workspace.
create_post: Create a post with body and optional channel_ids; add an ISO 8601 scheduled_at to schedule it, or omit it to save as a draft.
schedule_thread: Create an X thread from ordered tweets, optionally scheduling it.
list_scheduled: List posts scheduled to publish.
cancel_post: Cancel a scheduled post by post_id (returns it to draft).
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., "@@postbasehq/mcp Schedule this update for 9am tomorrow on X and LinkedIn"
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.
The Model Context Protocol server for Postbase, the open-source social media scheduler. Add it to Claude, Cursor or any MCP client and let your AI agent draft and schedule posts and threads to X, LinkedIn, Bluesky and Mastodon. (TikTok and YouTube need a video, so schedule those in the app.)
Post everywhere. Even from your AI.
Postbase also runs this server for you at https://mcp.postbase.so/mcp, with
OAuth sign-in instead of an API key. Add that URL as a custom connector in Claude
or ChatGPT, or as a remote MCP server in Cursor, VS Code, Windsurf, Claude Code or
Gemini CLI. The MCP config generator
prints the exact setup for each one.
Use this npm package when you want an API key instead, or a self-hosted Postbase.
Related MCP server: @posteverywhere/mcp
Create an API key in your Postbase dashboard under Developers.
Add the server to your MCP client config (see examples below).
Ask your agent: "Schedule this thread for 9am to X and Bluesky."
Any MCP client — the minimal config:
{
"mcpServers": {
"postbase": {
"command": "npx",
"args": ["@postbasehq/mcp"],
"env": { "POSTBASE_API_KEY": "pb_live_your_key_here" }
}
}
}Claude Desktop — add the same block to your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Then restart Claude Desktop.
Cursor — add it to ~/.cursor/mcp.json (or Settings → MCP):
{
"mcpServers": {
"postbase": {
"command": "npx",
"args": ["@postbasehq/mcp"],
"env": { "POSTBASE_API_KEY": "pb_live_your_key_here" }
}
}
}Local development — point at a Postbase instance running on your machine:
{
"mcpServers": {
"postbase": {
"command": "npx",
"args": ["@postbasehq/mcp"],
"env": {
"POSTBASE_API_KEY": "pb_live_your_key_here",
"POSTBASE_API_URL": "http://localhost:3000/api/v1"
}
}
}
}Tool | What it does |
| List the channels connected to your workspace. |
| Create a draft, or schedule a post or |
| How a post went on each channel: status, live URL, error, retry time and latest metrics. |
| Edit or reschedule a draft or scheduled post; only the fields you pass change. |
| Send a post again to the channels where it failed. |
| Impressions, likes, comments, shares and saves per post and channel, with totals. |
| List images and videos in your Postbase media library, to attach by id. |
| Add an image or video to the media library from a public https link. |
| List scheduled posts, or drafts, published or failed ones with |
| Cancel a scheduled post by id (it goes back to a draft). |
| Create a thread ( |
Variable | Required | Default |
| yes | — |
| no |
|
For local development against a Postbase instance on your machine, set
POSTBASE_API_URL=http://localhost:3000/api/v1.
AGPL-3.0-or-later. Part of the open-source Postbase project.
Cancel a scheduled post by id (returns it to draft).
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The id of the post to cancel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It expressly reveals the outcome ('returns it to draft'), which indicates that the post is not deleted but flipped back to draft state. It does not discuss permissions, failure cases, or publish handling, but the most critical behavioral trait is communicated.
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, 'Cancel a scheduled post by id (returns it to draft)', which is extremely concise and front-loads the core action. The parenthetical is an added, necessary behavioral acknowledgment. There is no padding or redundant content.
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?
This is a simple tool with one parameter and no output schema, so the description only needs to explain what the tool does – which it does clearly, including the post-replacement outcome. It gives enough context for an agent to invoke the tool correctly, and no additional guidance seems essential for this low-complexity operation.
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 already fully describes the single parameter post_id ('The id of the post to cancel'), and coverage is 100%. The tool description only re-states the id usage, adding no semantic layer beyond what the schema provides. Thus, the baseline 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 uses a specific verb 'Cancel' and a precise resource 'a scheduled post', plus the outcome 'returns it to draft'. It clearly distinguishes this from sibling tools like list_channels, create_post, and list_scheduled by stating exactly what action it performs on which entity.
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 this is the tool to use when a scheduled post needs to be cancelled, but it provides no explicit when-to-use, when-not-to-use, or alternatives. It does not mention sibling tools or prior steps such as obtaining the post_id from list_scheduled, so the guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a post. Provide channel_ids from list_channels and an ISO 8601 scheduled_at to schedule it (omit to save as a draft).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The post text. | |
| channel_ids | No | Channel ids to publish to (from list_channels). | |
| scheduled_at | No | ISO 8601 time to publish, e.g. 2026-09-12T09:00:00Z. Omit for a draft. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the draft-vs-schedule behavior and the dependency on list_channels, which is useful. However, it doesn't mention what happens on success (e.g., return value), whether the post is immediately published if scheduled_at is omitted, or any side effects like validation errors. The description is adequate but not rich.
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, compact sentence that front-loads the core action ('Create a post') and then packs the key usage details (channel_ids source, scheduled_at format, draft behavior) without waste. Every clause 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?
For a simple 3-parameter tool with no output schema, the description covers the essential usage: what to provide, where to get channel_ids, and how to schedule or draft. It doesn't explain return values or error cases, but given the simplicity and full schema coverage, the description is nearly complete. A brief note on success/return behavior would make it fully 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 description coverage is 100%, so the schema already documents all three parameters. The description adds a small amount of context by explaining the relationship between scheduled_at and draft behavior, and by pointing to list_channels for channel_ids. However, it doesn't add significant meaning beyond the schema, 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 clearly states the tool's purpose: creating a post, with explicit mention of scheduling and draft behavior. It distinguishes itself from siblings by referencing list_channels for channel_ids and by noting the omit-to-draft behavior, which differentiates it from cancel_post and list_scheduled.
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 clear context on when to use the tool: to create a post, optionally schedule it, or save as a draft. It doesn't explicitly state when not to use it or mention alternatives, but the sibling context and the mention of list_channels provide implicit guidance. A clear exclusion or alternative mention would push this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the social channels connected to the Postbase workspace.
| 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 carries the full burden. 'List' strongly implies a read-only operation, and there is no hint of destructive behavior. However, the description does not disclose details like authentication requirements, result ordering, pagination, or whether the list includes inactive/archived channels.
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 filler. It front-loads the action and resource, and every word contributes meaning.
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 no-parameter listing tool, the description covers the essential context: what is being listed and the workspace scope. The absence of an output schema is slightly mitigated by the straightforward nature of a list operation, but the return shape is not described. Still, the tool is simple enough that this is a minor gap.
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 tool accepts zero parameters and the schema has 100% coverage with an empty properties object. With no parameters to document, the baseline is 4, and the description does not need to add parameter-level meaning.
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') and a specific resource ('social channels connected to the Postbase workspace'). It clearly states what the tool does and is immediately distinguishable from sibling tools like create_post, list_scheduled, and cancel_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 this is the tool to use when you need an overview of connected channels, and the sibling names make alternatives fairly obvious. However, it does not explicitly state when to use this versus another tool or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts that are scheduled to publish.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only describes the core action and does not mention ordering, pagination, time-window semantics, whether already-published scheduled posts are included, or any permissions/auth requirements.
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, front-loaded sentence with no filler or redundancy. It gives the essential action and target resource in the most compact useful 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 zero-parameter, read-only list tool without an output schema, the description is mostly sufficient: an agent can identify what will be returned. It falls short of 5 only because it does not clarify the meaning or boundaries of 'scheduled to publish' (e.g., future-only, pending status, includes unpublished drafts).
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 tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline of 4 applies because parameter semantics are not a concern for this no-input tool.
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 states a specific verb ('List') and resource ('posts that are scheduled to publish'), clearly identifying the exact set of objects returned. It also distinguishes itself from siblings like list_channels (different resource) and create_post/cancel_post (different actions).
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 about when to use this tool versus the named siblings. While the purpose implicitly suggests it is for viewing scheduled posts, the description does not explicitly exclude alternatives or mention any conditions or context that should trigger its use.
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.
v0.1.0cancel_postcreate_postlist_channelslist_scheduledScored across 4 tools
Each tool targets a distinct action: listing channels, creating posts, listing scheduled posts, and canceling scheduled posts. There is no overlap or ambiguity between them.
All tool names follow the consistent verb_noun pattern in snake_case: list_channels, create_post, list_scheduled, cancel_post. The naming is uniform and predictable.
With only 4 tools, the server is tightly scoped for its purpose of managing social media post scheduling. Each tool is necessary and none are redundant.
The core workflow of creating, scheduling, and canceling posts is covered, but there are notable gaps: no way to list drafts, update an existing post, or permanently delete a post. Agents cannot fully manage the post lifecycle.
Draft, schedule and publish social posts to nine platforms from any AI agent.
Schedule and publish posts to X, Bluesky, Mastodon, LinkedIn and Reddit from your agent.
Draft, schedule and publish social media posts from any AI agent.
Schedule and publish social media posts to 10 platforms from your AI agent
