Agent Comms vs Content Distribution MCP
A side-by-side look at the Agent Comms and Content Distribution MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Agent Comms for communication work as a local process; choose Content Distribution MCP for communication as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Agent Comms when
- You need dedicated capabilities in the Communication domain.
- You prefer a local stdio subprocess transport.
Choose Content Distribution MCP when
- You need dedicated capabilities in the Communication domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: API key required.
- You want tools like
post_publish, post_schedule, post_drain.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Communication | Communication |
| Quality signal | 49/100 · Fair | 60/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | API key required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 34 | 5 |
| Directory activity | 0 views 0 installs 0 upvotes | 3 views 0 installs 0 upvotes |
| Tools | Not listed | 8 |
| Full listing | View Agent Comms | View Content Distribution MCP |
Tools & capabilities
Agent Comms tools
No tool names declared yet. Check the project README from the listing page.
Content Distribution MCP tools 8
post_publishPublish one or more channel variants immediately. Side effects: makes external HTTP requests to each channel platform; writes publish state to the local YAML backend; requires valid credentials in the named profile. Idempotent on (content.id, channel) — re-running with the same IDs returns cached state without re-posting. Use post_publish for immediate-only delivery; use post_schedule when any variant needs a future schedule_at; use post_drain to flush a previously built queue.post_scheduleEnqueue channel variants with schedule_at for future publishing; variants without schedule_at are published immediately. Side effects: writes entries to the local YAML schedule store; makes external HTTP requests for any immediately-published variants; requires credentials in the named profile. Idempotent on (content.id, channel). Use post_schedule when any variant needs a future publish time; use post_publish for all-immediate delivery; use post_drain to process the scheduled queue later.post_drainFire all scheduled posts due at or before the given time boundary. Side effects: makes external HTTP requests for each due entry; writes results to the YAML backend. Idempotent — already-published (content.id, channel) pairs are skipped; no-op when no entries are due. Safe to call from cron. Use post_drain on a recurring schedule to flush the queue; use post_publish or post_schedule to add new content; use post_status to inspect results after drain runs.post_statusReturn publish state for content pieces. Filters by content_id, channel, or both; returns all entries when neither is given. Side effects: read-only; no external HTTP calls; no auth needed. Deterministic given unchanged backend state. Use post_status to inspect what has been published, what is queued, or what errored; use post_publish, post_schedule, or post_drain to change state.post_unpublishBest-effort delete of a published post on the target platform. Side effects: makes an external HTTP DELETE or update request; DEV.to sets published=false (soft delete); platforms without a delete API return success=false without error. Non-idempotent — calling on an already-deleted URL may return a platform 404. Use post_unpublish to retract a live post; use post_status first to obtain the live_url; use post_publish to re-publish after an unpublish.channel_hintsReturn static per-channel metadata: character limits, Markdown support flags, tag vocabulary, and CTA placement rules. Side effects: read-only; no external HTTP calls; no auth needed. Fully deterministic — returns compile-time adapter constants. Use channel_hints before composing a variant body to understand channel constraints; use post_publish or post_schedule once you have a valid variant.profile_listReturn all distribution profile names configured in the YAML backend. Side effects: read-only; no external HTTP calls. Deterministic given backend state. Use profile_list to discover available profiles before calling post_publish, post_schedule, or subreddit_list; then pass the chosen name as profile_name.subreddit_listReturn all subreddits in the Subreddit Catalog with cooldown windows, flair vocabulary, and last-posted metadata. Optionally filtered to subreddits allowed by the named profile. Side effects: read-only; no external HTTP calls. Deterministic given backend state. Use subreddit_list to select a subreddit and obtain flair IDs before composing a reddit: channel variant; pass flair in variant.extras.flair.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Agent Comms
{
"mcpServers": {
"agent-comms": {
"command": "npx",
"args": [
"-y",
"agent-comms"
]
}
}
}
Content Distribution MCP
{
"mcpServers": {
"automatelab-tech-content-distribution-mcp": {
"command": "npx",
"args": [
"-y",
"@automatelab/content-distribution-mcp"
]
}
}
}
Frequently asked questions
Agent Comms is categorized under Communication and uses a local stdio subprocess. Content Distribution MCP belongs to Communication and uses a local stdio subprocess. Pick Agent Comms for communication work and Content Distribution MCP for communication.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Agent Comms has no declared pricing — check the project's own site. Content Distribution MCP is listed as free. Auth: api key required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add agent-comms and automatelab-tech-content-distribution-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Agent Comms has a quality signal of 49/100 (Fair) with 0 views, 0 installs and 34 GitHub stars. Content Distribution MCP has 60/100 (Good) with 3 views, 0 installs and 5 GitHub stars.