The Content Distribution MCP server enables publishing a single piece of content across multiple platforms with automatic adaptation, idempotency, scheduling, and state management. Here's what you can do:
Publish immediately — Send content variants to multiple channels at once (DEV.to, Hashnode, GitHub Discussions, Reddit, Bluesky, LinkedIn, Medium, Twitter). Idempotent: re-running with the same content ID and channel returns cached results without re-posting.
Schedule future posts — Queue variants with a schedule_at datetime for deferred delivery; immediate variants are published right away and scheduled entries are stored locally in YAML.
Drain the scheduled queue — Fire all scheduled posts due at or before a given time boundary. Safe to run from cron; already-published pairs are automatically skipped.
Check publish status — Inspect the current state (published, queued, errored) of any content piece across all channels, filterable by content ID and/or channel. Read-only, no external calls.
Unpublish posts — Best-effort deletion of a live post on a target platform (e.g., DEV.to performs a soft delete; platforms without a delete API return a failure indicator gracefully).
Get per-channel hints — Retrieve metadata for any channel: character limits, Markdown support flags, tag vocabulary, and CTA placement rules. Useful for composing valid variants before publishing.
List configured profiles — Discover all credential-backed distribution profiles configured in the local YAML backend.
List subreddits — Browse the Subreddit Catalog with cooldown windows, flair vocabulary, and last-posted timestamps, optionally filtered by profile.
Enables publishing content to Bluesky with automatic adaptation to platform-specific constraints such as character limits and formatting.
Allows publishing articles to DEV.to with automatic adaptation to platform-specific constraints including formatting and tag vocabularies.
Enables publishing content to GitHub Discussions with automatic adaptation to platform-specific constraints.
Allows publishing articles to Hashnode with automatic adaptation to platform-specific constraints.
Enables publishing content to Medium via browser fallback, returning a compose URL for manual posting when direct API is unavailable.
Allows publishing content to Reddit with automatic adaptation, enforcement of subreddit rules, and support for flairs and cooldowns.
Publish your content everywhere—without rewriting for every platform.
A MCP server that distributes a single piece of content across 8+ channels (DEV.to, Hashnode, GitHub Discussions, Reddit, Bluesky, LinkedIn, Medium, Twitter) with automatic platform-specific adaptation, idempotent publishing, per-community anti-spam rules, and centralized state management.
Creating and publishing content at scale is friction-heavy:
Different formats: Reddit strips formatting, Twitter has character limits, DEV.to supports embeds and rich media. Each needs customized copy.
Platform rules: Subreddits enforce cooldowns and flair requirements. Communities have posting patterns and automoderator gates. LinkedIn suppresses external links.
State chaos: Which posts went live where? What if a publish fails halfway? Did that Reddit post get auto-removed by spam filters?
This MCP handles distribution complexity. Write your core message once, generate platform-specific variants, publish everywhere safely.
Related MCP server: Pipepost
Your agent generates channel-specific copy variants (rewritten titles, trimmed text, platform-appropriate tags, audience-matched tone).
This MCP publishes each variant with idempotency, OAuth, API retries, and scheduling—enforcing platform constraints automatically.
You control which platforms get what. The MCP returns per-channel hints (character limits, tag vocabularies, cooldowns) but leaves creative decisions to you.
No LLM calls inside. No walled-in agents. Just a clean API for multi-platform content distribution at scale.
npx @automatelab/content-distribution-mcpOr add it permanently to your MCP host.
Claude Code — add to .claude/mcp.json:
{
"mcpServers": {
"content-distribution": {
"command": "npx",
"args": ["-y", "@automatelab/content-distribution-mcp"]
}
}
}Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"content-distribution": {
"command": "npx",
"args": ["-y", "@automatelab/content-distribution-mcp"]
}
}
}n8n — use the MCP Client node, point it at npx @automatelab/content-distribution-mcp over stdio.
Cursor / Windsurf / any MCP host — same npx -y content-distribution-mcp pattern.
The server reads credentials from a Distribution Profile stored in ~/.distribution-mcp/profiles.yaml:
# ~/.distribution-mcp/profiles.yaml
default:
credentials:
DEV_TO_API_KEY: "your-devto-api-key"
HASHNODE_TOKEN: "your-hashnode-token"
HASHNODE_PUBLICATION_ID: "your-pub-id"
GITHUB_TOKEN: "ghp_..."
GITHUB_DISCUSSION_REPO: "owner/repo"
REDDIT_CLIENT_ID: "..."
REDDIT_CLIENT_SECRET: "..."
REDDIT_USERNAME: "..."
REDDIT_PASSWORD: "..."
BLUESKY_IDENTIFIER: "you.bsky.social"
BLUESKY_PASSWORD: "..."
subreddits:
- ClaudeAI
- LocalLLaMAOnly set credentials for channels you intend to use. LinkedIn, Medium, and Twitter/X return needs_browser with a compose URL — no credentials needed.
Eight tools, dot-notation names form a navigable tree (post.*, channel.*, profile.*, subreddit.*). Every tool declares an outputSchema (callers can type-check responses) and MCP annotations (read-only / destructive / idempotent / open-world hints). No LLM calls inside the server.
Tool | Purpose |
| Immediate publish; idempotent on |
| Queue variants for |
| Fire all scheduled posts due now — run from cron |
| Per-channel state for a content piece or channel |
| Best-effort delete (DEV.to sets unpublished; others vary) |
| Per-channel metadata: char limits, Markdown support, tag vocab |
| Names of configured distribution profiles |
| Subreddit Catalog: cooldowns, flair vocab, last-posted |
v2.2.0 breaking change. Tools were renamed from flat names (
publish,schedule, ...) to dot-notation (post_publish,post_schedule, ...). Update any prompts, agent skills, or n8n nodes that referenced the old names.
Channel key | Tier | Auth |
| Auto |
|
| Auto |
|
| Auto |
|
| Auto-gated |
|
| Auto |
|
| Browser fallback | returns |
| Browser fallback | returns |
| Browser fallback | returns |
// post_publish tool
{
"content": {
"id": "n8n-webhook-setup@2026-05-20",
"title": "How to set up an n8n webhook",
"body_md": "...",
"tags": ["automation", "n8n", "tutorial"],
"canonical_url": "https://yourblog.com/n8n-webhook-setup",
"author": "You"
},
"variants": [
{
"channel": "devto:main",
"title": "How to set up an n8n webhook",
"body": "...",
"tags": ["automation", "n8n", "tutorial", "devops"],
"canonical_url": "https://yourblog.com/n8n-webhook-setup",
"extras": {}
},
{
"channel": "reddit:ClaudeAI",
"title": "Built a webhook automation with n8n",
"body": "Here's how I set it up...",
"tags": [],
"extras": { "flair": "Project" }
}
],
"profile_name": "default"
}Re-running post_publish with the same content.id + channel pair returns the existing live_url immediately without making another platform API call. Safe to retry on failure.
Variants with schedule_at (ISO-8601 with timezone, e.g. "2026-05-21T09:00:00+00:00") are stored in ~/.distribution-mcp/scheduled.yaml and fired on the next post_drain call. Run drain from cron:
# fire due posts every 5 minutes
*/5 * * * * npx -y content-distribution-mcp drainOr call the post_drain MCP tool directly from an agent.
Variable | Default | Purpose |
|
| State backend ( |
|
| Directory for YAML state files |
Node.js 18 or later
Agent (Claude Code / n8n / Cursor / any MCP host)
│ generates per-channel copy, calls MCP tools
▼
content-distribution-mcp (this package, stdio transport)
│ no LLM calls — pure I/O
├── adapters/ devto · hashnode · github-discussions · reddit · bluesky · browser
└── backends/ yaml (post log · profiles · schedule queue · subreddit catalog)No Anthropic-specific code anywhere. Verify:
grep -ri "anthropic" node_modules/content-distribution-mcp/dist/ # returns nothingagency-os — control plane
content-distribution-mcp — this package
automatelab.tech — blog and tutorials
MIT
Fire 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 drain on a recurring schedule to flush the queue; use publish or schedule to add new content; use status to inspect results after drain runs.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | ISO-8601 datetime boundary, e.g. '2026-05-21T09:00:00Z'; defaults to current UTC time when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: 'makes external HTTP requests for each due entry; writes results to the YAML backend'. Also states idempotence and no-op behavior. No annotations provided, so description fully handles 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?
Five concise sentences, each adding unique information: purpose, side effects, idempotence, usage guidance, and alternative tools. No redundancy or fluff.
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 only one parameter, no output schema, and no annotations, the description covers all needed aspects: what it does, side effects, idempotence, usage pattern, and related tools. 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 covers the parameter 'now' with a description. The description adds value by specifying default behavior: 'defaults to current UTC time when omitted'. Schema coverage is 100% so baseline is 3, but addition of default earns a 4.
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 'fire' and the resource 'scheduled posts due at or before a time boundary'. It differentiates from siblings by explicitly naming alternative tools: 'use publish or schedule to add new content; use status to inspect results after drain runs'.
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?
Provides explicit when-to-use ('on a recurring schedule to flush the queue'), when-not-to-use (use other tools for adding or inspecting), and additional context ('Safe to call from cron').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return 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 hints before composing a variant body to understand channel constraints; use publish or schedule once you have a valid variant.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Channel platform name, e.g. 'devto', 'reddit', 'hashnode', 'bluesky'. Use the platform prefix only, not the full 'platform:account' form. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral traits: read-only, no external calls, no auth needed, fully deterministic, returning compile-time constants. No contradictions.
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?
Three succinct sentences: purpose, behavior, usage. No redundancy, efficiently structured.
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?
Adequately covers return values (character limits, flags, vocabulary, CTA rules) and deterministic behavior. Lacks explicit return format but sufficient for a simple 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% with a clear description of 'channel'. The description adds extra context (use platform prefix only), enhancing parameter understanding 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 tool returns static per-channel metadata like character limits and Markdown support flags. It distinguishes itself from sibling tools by emphasizing read-only, deterministic behavior.
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?
Explicitly advises using hints before composing variant bodies and then using publish or schedule for a valid variant, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all distribution profile names configured in the YAML backend. Side effects: read-only; no external HTTP calls. Deterministic given backend state. Use list_profiles to discover available profiles before calling publish, schedule, or list_subreddits; then pass the chosen name as profile_name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: read-only, no external HTTP calls, deterministic given backend state. Since no annotations exist, the description fully covers behavioral expectations, matching the ideal for 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?
Two sentences: first explains output, second covers side effects and usage. Front-loaded, every sentence adds value, no redundancy.
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?
Despite lack of output schema and annotations, the description is fully complete: it specifies return type, side effects, and integration with sibling tools. No gaps.
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?
Tool has zero parameters, so schema coverage is 100% trivially. Baseline for 0 parameters is 4. Description adds no param info, which is fine since there are none.
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 it returns all distribution profile names from the YAML backend. It uses specific verb 'return' and resource, and distinguishes from siblings by positioning it as a prerequisite for publish, schedule, and list_subreddits.
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?
Explicitly instructs to use list_profiles before calling publish, schedule, or list_subreddits, and to pass the chosen profile_name. Provides clear context of when and why to use this tool relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return 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 list_subreddits to select a subreddit and obtain flair IDs before composing a reddit: channel variant; pass flair in variant.extras.flair.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_name | No | Optional profile name to filter subreddits to those allowed by that profile; omit to return the full catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects (read-only, no external HTTP calls) and determinism, which is critical for an agent. No annotations are provided, so the description fully compensates with clear behavioral traits.
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 three sentences, front-loaded with the primary purpose, followed by filtering and behavioral notes, then usage context. Every sentence adds value with no redundancy or fluff.
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, the description adequately explains return values (cooldown windows, flair vocabulary, last-posted metadata). It covers side effects, determinism, and parameter usage, making the tool's behavior fully understandable.
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 with a clear description for the profile_name parameter. The description adds only a paraphrased version ('allowed by that profile') but no additional constraints, formatting, or examples 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 tool returns all subreddits with metadata, using a specific verb 'Return'. It distinguishes from sibling tools (e.g., list_profiles returns profiles, not subreddits) and provides concrete use case context for composing reddit variants.
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 gives explicit guidance: use list_subreddits to select a subreddit and obtain flair IDs before composing a reddit channel variant. However, it does not explicitly mention when not to use this tool or suggest alternatives, missing some depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish 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 publish for immediate-only delivery; use schedule when any variant needs a future schedule_at; use drain to flush a previously built queue.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| variants | Yes | ||
| profile_name | Yes | Name of the distribution profile (credentials store). Use list_profiles to discover available names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses side effects (external HTTP requests, writes to YAML backend, requires valid credentials) and idempotency on (content.id, channel). Lacks detail on rate limits or error handling but is otherwise transparent.
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?
Three sentences, front-loaded with main action and side effects. No wasted words, covers purpose, side effects, idempotency, and sibling differentiation efficiently.
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, the description covers key aspects: what it does, side effects, idempotency, and usage guidance. Lacks detail on return values or error scenarios, but overall sufficient for the tool's complexity.
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 low (33%), but the description adds minimal parameter-specific meaning beyond 'requires valid credentials in the named profile.' It does not explain the complex content and variants nested objects, which the schema does document partially.
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 'Publish one or more channel variants immediately,' specifying the verb (publish) and resource (channel variants). It distinguishes from siblings like schedule (for future delivery) and drain (to flush queue).
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?
Explicitly provides when to use this tool versus alternatives: 'Use publish for immediate-only delivery; use schedule when any variant needs a future schedule_at; use drain to flush a previously built queue.' Also notes idempotency and credential requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enqueue 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 schedule when any variant needs a future publish time; use publish for all-immediate delivery; use drain to process the scheduled queue later.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| variants | Yes | ||
| profile_name | Yes | Name of the distribution profile (credentials store). Use list_profiles to discover available names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects: writes to YAML store, makes HTTP requests for immediate variants, requires credentials. States idempotent on (content.id, channel). No annotations provided, so description fully covers behavior.
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 concise (5 sentences), front-loaded with purpose and usage, no redundant information. Every sentence 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?
Covers purpose, usage, side effects, idempotency, and alternatives. Missing explanation of return value/output (no output schema), though complexity and sibling differentiation are well-handled.
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 33% (low), requiring description to compensate. However, description only mentions schedule_at in context, not other parameters like content, variants, profile_name. Insufficient addition beyond 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 tool enqueues channel variants with schedule_at for future publishing and immediately publishes those without. It distinguishes from siblings: schedule for mixed timing, publish for all-immediate, drain for processing queue.
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?
Explicitly tells when to use this tool versus alternatives: schedule when any variant needs future time, publish for immediate, drain for processing. Also mentions prerequisites (credentials) and idempotency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return 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 status to inspect what has been published, what is queued, or what errored; use publish, schedule, or drain to change state.
| Name | Required | Description | Default |
|---|---|---|---|
| content_id | No | Filter to a specific content piece by its stable ID; omit to return state for all content. | |
| channel | No | Filter to a specific channel slug, e.g. 'devto', 'reddit:ClaudeAI'; omit to return state for all channels. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it is read-only, makes no external HTTP calls, requires no authentication, and is deterministic given unchanged backend state. This is comprehensive and adds significant context beyond what annotations would provide.
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 three sentences, each earning its place: purpose and filters, side effects, usage guidance. It is front-loaded and contains no verbose or redundant 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 the tool's simplicity (2 optional params, no output schema), the description is fully sufficient. It covers what the tool returns (publish state), how to filter, its side effects, and how it relates to sibling tools. There are no gaps.
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 baseline is 3. The description adds value by explaining the combination behavior of the two filters and the default behavior when neither is given ('returns all entries when neither is given'). This goes beyond the schema's individual parameter 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 starts with 'Return publish state for content pieces', which is a specific verb+resource. It distinguishes itself from sibling tools by explicitly mentioning that state-changing operations should use other tools (publish, schedule, drain).
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 explicit guidance on when to use the tool ('inspect what has been published, what is queued, or what errored') and when not to ('use publish, schedule, or drain to change state'). This makes the decision boundary very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best-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 unpublish to retract a live post; use status first to obtain the live_url; use publish to re-publish after an unpublish.
| Name | Required | Description | Default |
|---|---|---|---|
| live_url | Yes | URL of the live published post to retract, e.g. 'https://dev.to/user/post-slug'. | |
| channel | Yes | Channel slug the post was published to, e.g. 'devto', 'hashnode', 'reddit:ClaudeAI'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses non-idempotency, side effects (HTTP DELETE, soft delete on DEV.to), and error scenarios (platform 404, success=false). This provides comprehensive behavioral understanding.
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 and front-loaded with purpose. It could be more structured (e.g., bullet points) but every sentence is valuable and avoids redundancy.
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 tool's complexity (2 required params, no output schema, no annotations), the description covers purpose, behavior, side effects, idempotency, and workflow integration with siblings. It leaves no critical gaps for an AI agent.
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 good parameter descriptions. The description adds practical context, such as that live_url is obtained from status and channel includes platforms like devto, hashnode, etc. This adds value 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 tool's action ('best-effort delete of a published post') and distinguishes it from siblings like publish, status, and drain. It uses specific verbs and resources.
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?
Explicit guidance is given on when to use this tool ('Use unpublish to retract a live post') and how to combine with siblings ('use status first to obtain the live_url; use publish to re-publish'). However, it does not explicitly state 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0drainhintslist_profileslist_subredditspublishschedulestatusunpublishEach tool targets a distinct function: flushing, metadata retrieval, listing, publishing, scheduling, status checking, and deletion. No two tools have overlapping purposes, ensuring clear selection.
Most tools follow a verb pattern (drain, publish, schedule, unpublish) or list_ prefix (list_profiles, list_subreddits), but hints and status are nouns. The inconsistency is minor and does not hinder understanding.
Eight tools is well-scoped for a content distribution server, covering core operations without being overwhelming. Each tool has a clear role.
The tool set covers the full lifecycle: discovery (list_profiles, list_subreddits, hints), publishing (publish, schedule, drain), status checking (status), and deletion (unpublish). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A free social media scheduler your AI tools can post through — LinkedIn, Bluesky, Mastodon, YouTube.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Post & schedule to 32+ networks: X, Facebook, Instagram, Threads, LinkedIn, TikTok, YouTube, Reddit.
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AutomateLab-tech/content-distribution-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
