This server is an MCP-compliant content publisher that enables publishing posts and retrieving statistics across social media platforms (Telegram – real, YouTube & Instagram – mock).
Publish posts (publish_post): Publish text (with HTML formatting support for Telegram) and optional media to a specified channel. Supports scheduling via ISO-8601 timestamps.
Retrieve post metrics (get_metrics): Fetch engagement data including views, reactions, reposts, and comments (Telegram metrics are mock in MVP).
Get channel statistics (get_channel_stats): Obtain overall channel performance: subscriber count, weekly post count, and average views per post.
Flexible deployment: Integrate via stdio with MCP hosts or access remotely via SSE for debugging. Requires configuration with platform API tokens (e.g., Telegram Bot Token).
Provides a bridge tool for integrating the MCP server with CrewAI agents, enabling content publishing and analytics.
Planned integration for publishing content and retrieving metrics on Instagram.
Allows publishing posts (text and media) to Telegram channels and retrieving metrics via Bot API.
Planned integration for publishing content and retrieving metrics on YouTube.
Click on "Install 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., "@MCP Content Publisher publish 'Hello world' to Telegram channel @my_channel"
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.
MCP-сервер для публикации контента и сбора метрик на социальных платформах. Реализует протокол MCP (Model Context Protocol).
Платформа | Публикация | Метрики | Статус |
Telegram | ✅ Bot API (sendMessage / sendPhoto) | 🚧 Заглушка (V2: Telethon) | Работает, протестировано |
YouTube | 🚧 Заглушка | 🚧 Заглушка | План |
🚧 Заглушка | 🚧 Заглушка | План |
Related MCP server: meta-mcp
# Установка через uv
uv sync
# С тестовыми зависимостями
uv sync --group testСкопируйте .env.example в .env и укажите токен бота:
cp .env.example .env# TELEGRAM
TELEGRAM_BOT_TOKEN="токен_от_BotFather"Токен создаётся через @BotFather в Telegram.
# stdio (для интеграции с MCP-хостами — Claude Desktop, Cline и др.)
uv run mcp-content-publisher
# SSE (для отладки и удалённого доступа)
uv run mcp-content-publisher --transport sse --host 127.0.0.1 --port 8001# Сборка образа
docker build -t mcp-content-publisher .
# Запуск контейнера (порт только на localhost)
docker run -d --name mcp-content-publisher \
-p 127.0.0.1:8001:8001 \
--env-file .env \
mcp-content-publisher
# Проверка healthcheck
docker ps# На VPS: скопировать проект, создать .env
cp .env.example .env
# → вписать TELEGRAM_BOT_TOKEN
# Сборка и запуск
docker compose up -d --build
# Логи
docker compose logs -f
# Остановка
docker compose downСимптом: publish_post возвращает HTTP request failed: (пустая ошибка), хотя
остальной интернет с сервера работает. Часто это маршрутизация провайдера к
подсетям Telegram, а не Docker. Быстрая проверка с хоста (таймаут → прокси нужен):
curl -s -o /dev/null -w "%{http_code}\n" https://api.telegram.org/bot<TOKEN>/getMeРешение — направить исходящий HTTPS контейнера через прокси (должен принимать
HTTP CONNECT или SOCKS5). Добавьте в .env:
HTTPS_PROXY="http://user:pass@proxy_host:port"
HTTP_PROXY="http://user:pass@proxy_host:port"
NO_PROXY="127.0.0.1,localhost"
NO_PROXY=127.0.0.1,localhostобязателен — иначе healthcheck (SSE на localhost) тоже уйдёт через прокси. Публикация медиа (multipart → Bot API) идёт тем же путём — прокси покрывает и её.
Пересоздать контейнер, чтобы применить .env:
docker compose up -d --force-recreateПроверка изнутри контейнера (ожидается 200):
docker exec mcp-content-publisher python -c \
"import urllib.request,os; r=urllib.request.urlopen('https://api.telegram.org/bot'+os.environ['TELEGRAM_BOT_TOKEN']+'/getMe', timeout=15); print(r.status)"Безопасность: сервер не имеет аутентификации, поэтому не должен быть доступен снаружи. В Docker-конфиге порт проброшен только на
127.0.0.1, а сервер слушает только localhost. Доступ — исключительно через SSH-туннель.
На локальной машине поднимите туннель до VPS:
ssh -L 8001:127.0.0.1:8001 root@<IP-VPS>После этого сервер доступен локально:
http://127.0.0.1:8001/sseПример конфигурации для Claude Desktop / Cline:
{
"mcpServers": {
"content-publisher": {
"transport": "sse",
"url": "http://127.0.0.1:8001/sse"
}
}
}Если всё же нужно открыть сервер наружу (например, за reverse-proxy с basic-auth), потребуется:
Пробросить порт на все интерфейсы в docker-compose.yml:
ports:
- "8001:8001"Разрешить внешний Host-заголовок в .env (MCP SDK блокирует незнакомые Host заголовки кодом 421 — защита от DNS-rebinding):
MCP_ALLOWED_HOSTS="<IP-или-домен>:*"Несколько хостов — через запятую: "5.129.207.137:*,mcp.example.com:*"
MCP_ALLOWED_HOSTS="*" — отключить защиту (любой Host)
Не задано — только localhost (по умолчанию)
127.0.0.1, localhost, [::1] разрешены всегда (нужны для healthcheck).
publish_postОпубликовать пост на указанной платформе.
Параметры:
platform (str): telegram | youtube | instagram
text (str): Текст поста. Поддерживает HTML-разметку (<b>, <i>, <code>, <a href="...">)
channel (str): Канал для публикации — @username, chat ID или invite link
media_urls (list[str], optional): изображение/видео — URL (https://…), локальный путь (/app/output/cover.png) или file:// URL
schedule_at (str, optional): Время публикации в ISO-8601
Пример:
{
"platform": "telegram",
"text": "<b>Привет!</b> Это тестовый пост из MCP сервера",
"channel": "-1001234567890"
}Ответ:
{
"post_id": "42",
"status": "published",
"url": "https://t.me/channel/42",
"error": null
}Медиа (фото): если передать в media_urls локальный путь или file:// URL —
файл загружается в Telegram через multipart (sendPhoto с files), внешние
URL и публичный хостинг не нужны. Это важно на серверах, где Telegram заблокирован
(см. секцию про прокси) и для локально-генерируемых обложек. HTTP(S)-URL и
file_id по-прежнему передаются как есть.
get_metricsПолучить метрики опубликованного поста.
Параметры:
platform (str): Платформа
post_id (str): ID поста на платформе
Ответ:
{
"post_id": "42",
"platform": "telegram",
"views": 150,
"reactions": 12,
"reposts": 3,
"comments": 2
}Примечание: Telegram Bot API не отдаёт реальные просмотры/реакции. В MVP возвращаются mock-данные. В V2 планируется Telethon (MTProto) для реальных метрик.
get_channel_statsПолучить общую статистику канала.
Параметры:
platform (str): Платформа
channel (str): Имя/ID канала
Ответ:
{
"platform": "telegram",
"channel": "@channel",
"subscribers": 1000,
"posts_this_week": 5,
"avg_views": 200
}Telegram провайдер автоматически определяет режим разметки:
HTML — если в тексте есть HTML-теги (<b>, <i>, <code>, <a>)
HTML (по умолчанию) — для обычного текста (не требует экранирования)
Поддерживаемые HTML-теги в Telegram: <b>, <i>, <u>, <s>, <code>, <pre>, <a href="...">
# Запуск всех тестов
uv run pytest tests/ -v
# Только unit-тесты
uv run pytest tests/test_publish_server.py -v
# Только интеграционные тесты (MCP протокол)
uv run pytest tests/test_mcp_server_integration.py -vМодели — Pydantic-схемы (PublishContent, PublishResult, PostMetrics, ChannelStats)
Провайдеры — Telegram (токен, публикация, метрики), YouTube/Instagram (mock)
Реестр провайдеров — синглтон, неизвестные платформы
MCP сервер — регистрация инструментов, вызов через MCP протокол
mcp-content-publisher/
├── src/mcp_content_publisher/
│ ├── server.py # MCP сервер (точка входа)
│ ├── models.py # Pydantic-схемы
│ └── providers/
│ ├── base.py # Базовый класс PublishProvider
│ ├── telegram.py # Telegram Bot API
│ ├── youtube.py # YouTube (заглушка)
│ └── instagram.py # Instagram (заглушка)
├── tests/
│ ├── test_server.py # Тесты MCP сервера
│ ├── test_publish_server.py # Тесты провайдеров и моделей
│ └── test_mcp_server_integration.py # Интеграционные тесты
├── .env.example
└── pyproject.toml# Установка с dev-зависимостями
uv sync --group test
# Запуск тестов
uv run pytest
# Проверка типов
uv run mypy src/Получить общую статистику канала.
Args: platform: Платформа (telegram | youtube | instagram) channel: Имя/ID канала
Returns: ChannelStats: {platform, channel, subscribers, posts_this_week, avg_views}
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| platform | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output fields but does not disclose behavior such as real-time vs cached data, required permissions, rate limits, or error handling. The read-only nature is implied but not explicit.
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 a clear heading, Args and Returns sections. It avoids fluff and is front-loaded with the main action. However, it mixes languages (Russian and English) which may reduce clarity for some agents.
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 read tool with two parameters and no output schema, the description covers the basics: purpose, inputs, and output structure. It lacks details on error cases, data freshness, and pagination (if any), but is minimally adequate.
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 0%, but the description adds meaning for both parameters: platform is clarified with allowed values (telegram, youtube, instagram) and channel as name/ID. This adds value beyond the bare schema, though it does not provide format examples or constraints.
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: 'Получить общую статистику канала' (get general channel statistics). It identifies the resource (channel) and the verb (get stats). However, it does not differentiate from sibling tools like get_metrics, missing an opportunity to clarify scope.
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 an Args section listing required parameters but gives no guidance on when to use this tool versus alternatives like get_metrics or publish_post. There is no context about prerequisites, frequency caps, or suitability for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить метрики опубликованного поста.
Args: platform: Платформа (telegram | youtube | instagram) post_id: ID поста на платформе
Returns: PostMetrics: {post_id, platform, views, reactions, reposts, comments}
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ||
| platform | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behaviors. It reveals the return structure (PostMetrics fields) but lacks details on error handling, permissions, or rate limits.
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?
One sentence plus structured Args/Returns. All essentials are front-loaded with no extraneous 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?
Covers inputs and output structure. For a 2-param tool with no output schema, it is nearly complete, though it could mention that the post must be published.
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 0%, so description adds value by explaining platform with examples (telegram | youtube | instagram) and post_id context, going beyond the raw 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 'Получить метрики опубликованного поста' (Get metrics of a published post), uses specific parameters (platform, post_id), and contrasts with siblings get_channel_stats (channel-level) and publish_post (publishing).
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 explains the parameters and implies when to use (for a specific post), but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Опубликовать пост на указанной платформе.
Args: platform: Платформа (telegram | youtube | instagram) text: Текст поста channel: Канал для публикации (@username или ID) media_urls: URL изображений/видео (опционально) schedule_at: Время публикации в ISO-8601 (опционально)
Returns: PublishResult: {post_id, status, url, error}
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| channel | Yes | ||
| platform | Yes | ||
| media_urls | No | ||
| schedule_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses publishing behavior, optional scheduling, media URLs, and return fields (post_id, status, url, error). It does not mention side effects or rate limits, but covers the core behavior sufficiently.
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 structured with a one-line purpose, then a bullet-style Args and Returns section. It is concise and easy to parse, though the Russian language might limit international agents.
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 includes the return structure. All 5 parameters are explained. It lacks error handling details but is sufficient for correct invocation in most cases.
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 0%, but the description provides full parameter semantics: platform options (telegram | youtube | instagram), text, channel, media_urls optional, schedule_at optional with ISO-8601 format. This adds significant value beyond the bare 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 'Опубликовать пост на указанной платформе' (Publish a post on the specified platform), specifying the verb and resource. It lists the allowed platforms and distinguishes itself from sibling tools (get_metrics, get_channel_stats) which are read-only.
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 does not explicitly provide when to use this tool versus alternatives. However, the sibling tool names and context imply usage for publishing vs. reading metrics, so it is adequate 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. Dates show when Glama detected each change.
v0.1.0get_channel_statsget_metricspublish_postEach tool has a clearly distinct purpose: publishing a post, getting metrics for a post, and getting channel statistics. No overlap or ambiguity.
All tools follow a consistent verb_noun snake_case pattern (publish_post, get_metrics, get_channel_stats), making it easy to predict functionality.
With only 3 tools, the server is minimal but functionally complete for basic publishing and stats retrieval. Slightly limited but appropriate for its stated purpose.
The server provides publish and read operations but lacks update/delete tools for posts, and no tool to list or manage scheduled posts. Significant lifecycle gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Social media MCP: publish, schedule & analyze posts on TikTok, Instagram, YouTube, LinkedIn & X
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ESkuratov/mcp-content-publisher'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
