Social Publish MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SOCIAL_PUBLISH_HOME | No | State folder | ~/.social-publish-mcp |
| SOCIAL_PUBLISH_PORT | No | Bridge port (set the same port in the extension popup) | 8797 |
| SOCIAL_PUBLISH_EXTENSION_IDS | No | Extra extension ids to accept, comma separated |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| publishA | Upload one video to one platform through the user's logged-in Chrome, and publish or schedule it. Only call this after the user approved this exact post (video, text, platform, time). platform: "youtube" | "facebook" | "tiktok". video: absolute path of the video file on this computer. caption: YouTube description / Facebook reel description / TikTok caption, hashtags included, written as-is. title: YouTube title (required for YouTube, max 100 chars; ignored elsewhere). tags: YouTube tags. schedule_at: ISO 8601 with UTC offset (e.g. "2026-11-01T17:00+02:00"); omit to publish now. options: youtube {channel_id, playlists, made_for_kids, altered_content, visibility}; facebook {asset_id, allow_remix}; tiktok {visibility, ai_generated, allow_comments}. dry_run: fill everything but stop before the final Publish/Schedule click (use it first for a new template). keep_tab: leave the tab open afterwards (to look at a dry run). Returns {ok, results:[{platform, ok, status, url, post_id, scheduled_for, message, screenshot}]}. |
| publish_batchA | Run several posts: e.g. one video to three platforms at once, or a week of scheduled posts. Only call this after the user approved every post in the batch. jobs: list of {platform, video, caption, title?, tags?, schedule_at?, options?} (same fields as publish; caption_file may replace caption). All jobs are validated first: if one is invalid nothing runs. Jobs run in parallel tabs (max_parallel), but one job per platform at a time. Returns {ok, results:[...]} in the input order. |
| check_accountsA | Open each platform's upload page in Chrome and report which account is logged in (tabs are closed after). platforms: any of "youtube", "facebook", "tiktok" (default: all). Returns {platform: {logged_in, account, detail}}. |
| statusA | Is the Chrome extension connected? Server/extension versions, running jobs, open tabs, last results. |
| historyA | The last |
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 5 tools
Each tool has a distinct role: publish for one post, publish_batch for multiple jobs, check_accounts for login detection, status for connection/job state, and history for past results. The only mild overlap is publish vs publish_batch for a single job, but the batch description clearly frames it as multi-post execution with all-or-nothing validation.
Mostly readable, but conventions are mixed: publish and publish_batch are verb-based, check_accounts is verb_noun, while status and history are bare nouns. The names are predictable enough to use, but do not follow a single consistent pattern.
Five tools is well-scoped for a social publishing server: one core action, a batch variant, account validation, connection status, and history. Each tool clearly earns its place without redundancy.
Core publishing, scheduling, batching, account checks, status, and history are covered. However, there is no explicit cancel/delete or list-scheduled-posts operation, which are notable gaps for a toolset that supports scheduling, forcing agents to work around via browser tabs or history.