This server provides MCP tools to analyse YouTube videos and X/Twitter feeds, generate infographics, and sync results to GitHub.
Analyse a YouTube video — extracts transcript and generates key takeaways, TLDR, and social hook.
Batch analyse multiple YouTube videos from a list of URLs or a config file.
Fetch recent videos from a YouTube channel.
Analyse recent X/Twitter posts from specified or default accounts, with topic filtering and time range.
Generate a comic-book style infographic image from analysis results.
Sync video analyses, X digests, and images as markdown files to a GitHub repository.
Syncs analysis results and generated images to a specified GitHub repository as markdown files.
Generates comic-book style infographics using the Gemini API for visual summaries of analyzed content.
Analyzes YouTube videos by extracting transcripts and generating summaries, key takeaways, TLDRs, and social hooks.
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., "@mcp-content-pipeline Analyse this YouTube video and generate a comic infographic: https://youtu.be/xyz"
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.
A content analysis and digest pipeline for YouTube videos and X (Twitter) feeds, exposed as MCP tools: extract transcripts, fetch posts from curated accounts, generate key takeaways/TLDRs/social hooks/infographics, sync to GitHub.
flowchart LR
A[YouTube URL<br/>or X feed] --> B[Extract content<br/>Supadata / X API]
B --> C[LLM analysis<br/>takeaways, TLDR, hook]
C --> D[Gemini image<br/>comic infographic]
D --> E[Sync to GitHub<br/>markdown + image]Uses: mcp-llm-eval for evaluation and CI quality gates
Produces: benchmark JSON written to llm-benchmarks under text-generation/content-pipeline-*.json
Visible at: LLMShot's Text Generation domain, Content Pipeline sub-benchmark
The eval dataset (eval/dataset.json) lives with this repo because the questions are specific to YouTube and X feed analysis — the dataset belongs with the use case, not the engine.
Related MCP server: gobbler-mcp
git clone https://github.com/berkayildi/mcp-content-pipeline.git
cd mcp-content-pipeline
cp .env.example .env # fill in the keys for the tools you use
uv syncAll config lives in a local .env (gitignored). On startup the server loads the nearest .env from its working directory upwards; set MCP_CP_ENV_FILE to load one from an explicit path instead. Variables already present in the process environment take precedence over .env.
Launch the server from the clone so it picks up .env — the same block works for Claude Desktop, Claude Code (.mcp.json), and other MCP clients:
{
"mcpServers": {
"content-pipeline": {
"command": "uv",
"args": ["run", "--directory", "/path/to/mcp-content-pipeline", "mcp-content-pipeline"]
}
}
}To run the published package without a clone, use uvx mcp-content-pipeline and point it at your .env:
{
"mcpServers": {
"content-pipeline": {
"command": "uvx",
"args": ["mcp-content-pipeline"],
"env": { "MCP_CP_ENV_FILE": "/path/to/.env" }
}
}
}YouTube Analysis
"Use content-pipeline to analyse this video: https://www.youtube.com/watch?v=..." "Generate an image for this analysis" "Sync the analysis and image to GitHub"
Or all in one prompt:
"Use content-pipeline to analyse this video, generate the image, and sync to GitHub: https://www.youtube.com/watch?v=..."
X Feed Digest
"Analyse the X feed" "Analyse the X feed for karpathy, bcherny, atmoio, and steipete about AI today" "Analyse the X feed from the last 7 days"
Or with the full pipeline:
"Analyse the X feed, generate the image, and sync to GitHub"
Tool | Description | Requires |
| Analyse a single YouTube video — transcript, takeaways, TLDR, social hook |
|
| Analyse multiple videos from a URL list or config file |
|
| Fetch recent videos from a YouTube channel |
|
| Push analyses as markdown files to a GitHub repo |
|
| Analyse recent posts from curated X accounts — daily digest |
|
| Generate comic-book infographic from analysis result |
|
All prefixed with MCP_CP_ and set in .env — see .env.example for a ready-to-copy template.
Pipeline driver — required for analyse_video, batch_analyse, analyse_x_feed
Variable | Required | Description |
| No |
|
| Yes | API key for the selected provider |
| No | Model name valid for the selected provider (default: |
YouTube — required for analyse_video, batch_analyse
Variable | Required | Description |
| Yes | Transcript extraction |
| No | Only for |
| No | Default: |
GitHub — required for sync_to_github
Variable | Required | Description |
| Yes | Personal access token |
| Yes | Target repo, |
| No | Default: |
| No | Default: |
| No | Default: |
X/Twitter — required for analyse_x_feed
Variable | Required | Description |
| Yes | X API v2 bearer token |
| No | Default usernames, comma-separated — required unless |
| No | Default: |
Image generation — required for generate_image
Variable | Required | Description |
| Yes | Google AI Studio API key |
| No | Default: |
| No | Default: |
Estimated monthly costs for two usage patterns:
Service | Daily (every day) | Weekly X + daily YouTube |
YouTube analysis (LLM API) | ~$3–5/mo (1 video/day) | ~$3–5/mo (1 video/day) |
X feed digest (LLM API) | ~$2–3/mo | ~$0.50/mo |
Image generation (Gemini API) | ~$2/mo ($0.067/image) | ~$2/mo ($0.067/image) |
X API reads | ~$4/mo ($0.13/day) | ~$0.60/mo ($0.15/week) |
Supadata transcript API | ~$0 (free tier: 100/mo) | ~$0 (free tier: 100/mo) |
Total (excl. LLM API) | ~$6–9/mo | ~$3–5/mo |
LLM costs are estimated for the default
claude-sonnet-4-6driver and vary withPIPELINE_PROVIDER/PIPELINE_MODEL; they are billed per token by the provider's API (a chat subscription such as Claude Pro does not cover API usage) and are not included in the totals. The X API spending cap can be configured in the developer console.
Subscription | Monthly cost | What the pipeline covers instead |
Google One AI Premium | ~$20/mo | Image generation via Gemini API (~$2/mo) |
X Premium | ~$8/mo | X feed reading via API (~$0.60–4/mo) |
YouTube Premium | ~$14/mo | Transcript extraction via Supadata (free tier) |
Total saved | ~$42/mo | Pipeline cost: ~$3–9/mo (plus LLM API usage) |
PRs touching services/, tools/, config.py, server.py, eval/, .eval-gate.yml or pyproject.toml trigger a CI run via mcp-llm-eval, scoring faithfulness/relevance across 8 models against a reference dataset; the PR is blocked below configured thresholds.
See .eval-gate.yml for threshold configuration and eval/dataset.json for the test dataset.
The benchmark requires API keys for all three providers. Add them to the same .env (unprefixed — they are read by mcp-llm-eval, not the server):
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
GOOGLE_API_KEY=AIza...Then run:
make benchmark # Run eval against all 8 models
make benchmark-copy # Copy results to llm-benchmarks repoResults are written to eval/results/ (gitignored) and feed LLMShot via the llm-benchmarks repo (text-generation/content-pipeline-{summary,benchmark}.json).
powers CI quality gates. The pipeline's own driver (
MCP_CP_PIPELINE_PROVIDER) is configurable at runtime — see Environment Variables above.
uv run mcp-content-pipeline # run the server from the clone
uv run pytest -v --cov=src/mcp_content_pipeline
uv run ruff check src/ tests/Credentials live in a local .env (gitignored, see .env.example) — never committed, and never in MCP client config
All API keys stay on your machine; nothing is sent anywhere but the configured providers
Fork the repository
Create a feature branch (git checkout -b feat/my-feature)
Commit using Conventional Commits (feat: add new feature)
Push and open a Pull Request
Analyse a single YouTube video — extracts transcript, generates key takeaways, TLDR, and social hook.
Use this tool when the user provides a YouTube URL or asks to analyse a YouTube video. Supports youtube.com/watch, youtu.be, youtube.com/shorts, and youtube.com/live URLs. Works with videos in any language.
Args: url: YouTube video URL custom_prompt: Additional analysis instructions (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| custom_prompt | No |
| Name | Required | Description |
|---|---|---|
| result | 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 fails to disclose any behavioral traits such as side effects (none expected), authentication requirements, rate limits, or whether it modifies data. The description only mentions outputs without transparency on operational aspects.
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 paragraphs plus Args section, front-loaded with key info. Some redundancy in listing URL formats, but overall efficient. Every sentence contributes to understanding.
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 and that an output schema exists (not shown), the description covers core functionality but lacks details on error handling, video availability issues, or input validation. It is adequate but has gaps in completeness.
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 0%, so the description must add meaning. The Args section provides brief explanations: 'url: YouTube video URL' and 'custom_prompt: Additional analysis instructions (optional)'. The general description also lists supported URL formats. This adds some value but does not fully compensate, e.g., no detail on what 'additional analysis instructions' entails.
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 'analyse' and the resource 'a single YouTube video', and lists specific outputs (transcript, key takeaways, TLDR, social hook). It distinguishes from siblings by focusing on single video and YouTube platform.
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 states when to use: when user provides a YouTube URL or asks to analyse a YouTube video. Lists supported URL formats. Does not explicitly state when not to use or mention alternatives, but the context implies single-video use only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse recent X (Twitter) posts and tweets from specified accounts or configured defaults.
Fetches posts from X/Twitter user timelines, filters by topic, and generates a digest with key takeaways, TLDR, social hook, and notable posts. Use this tool when the user asks about X posts, tweets, Twitter feed, what someone posted on X, or wants a digest of X/Twitter activity.
Args: usernames: X/Twitter usernames to analyse (defaults to configured MCP_CP_X_ACCOUNTS) topics: Topics to focus on (defaults to configured MCP_CP_X_TOPICS) hours_back: How far back to fetch posts (default: 24, use 168 for weekly)
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | No | ||
| topics | No | ||
| hours_back | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes fetching, filtering, and generating digest, but lacks details on authentication, rate limits, or data freshness. Adequate but not comprehensive.
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?
Well-structured with clear sections: purpose, usage hint, and argument details. Slight redundancy in first sentence but overall concise.
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 all necessary aspects for a feed analysis tool: what it does, parameters, defaults, usage context. Output schema exists, so return values are not needed.
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 description explains each parameter well: usernames (defaults to configured), topics (defaults to configured), hours_back (default 24, suggests 168 for weekly). Adds significant value 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 it analyzes X/Twitter posts and generates a digest. It distinguishes well from sibling tools (analyse_video, batch_analyse, etc.), which have different purposes.
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 ('when user asks about X posts, tweets...'). Does not mention when not to use, but siblings are unrelated, making context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse multiple YouTube videos from a list of URLs or a config file path.
Args: urls: List of YouTube URLs to analyse config_file: Path to a YAML/JSON file containing a list of URLs
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | ||
| config_file | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behaviors such as read-only vs. destructive, authentication needs, rate limits, or what 'analyse' entails. The description adds minimal context beyond the schema.
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 main description is a single concise sentence. The additional Args section provides necessary parameter details. It is appropriately sized with no wasted 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?
Given the batch nature and output schema existence, the description could mention handling of multiple URLs, limits, or result aggregation. It is adequate but lacks some context for a complex batch 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?
With 0% schema description coverage, the description compensates by explaining the urls parameter as 'List of YouTube URLs to analyse' and config_file as 'Path to a YAML/JSON file containing a list of URLs'. This adds meaning beyond the schema types.
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 analyzes multiple YouTube videos from URLs or a config file. It distinguishes itself from sibling tools like analyse_video (single video) and analyse_x_feed (X/Twitter feed).
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 explicit guidance on when to use this tool versus alternatives (e.g., analyse_video for single videos). The description implies batch usage but does not state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comic-book style infographic image from a video analysis or X digest result.
Creates a visual summary with bold colours, panel divisions, and text labels. Use after analyse_video or analyse_x_feed to create a shareable infographic.
Args: analysis: Analysis result object from analyse_video, batch_analyse, or converted X digest
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output style (comic-book, bold colours, panel divisions, text labels) and implies it creates a visual summary, but does not discuss potential side effects, authentication, rate limits, or whether the image is saved or returned. Adequate but not thorough.
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 three short sentences front-loading the purpose and usage context. The Args section is straightforward, though it partially repeats earlier information. No unnecessary 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?
The tool has one complex required parameter and no annotations, but an output schema exists. The description does not explain what the output is (e.g., file format, storage location) beyond 'visual summary'. With the output schema available, the description could be more complete by noting the output's nature or additional constraints.
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 0%, so the description must compensate. The 'Args' section only states the analysis parameter is a result object from certain tools, without detailing its structure or required fields. The schema allows any additional properties, offering no clarity, leaving the agent to infer the object's format.
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 explicitly states the tool generates a comic-book style infographic image from a video analysis or X digest result, clearly identifying the resource and verb. It distinguishes from sibling tools by specifying it should be used after analyse_video or analyse_x_feed, making its purpose unmistakable.
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 guidance on when to use the tool: after analyse_video or analyse_x_feed, and also mentions batch_analyse as an alternative source. While it doesn't explicitly state when not to use it, the context is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent videos from a YouTube channel (requires YouTube Data API key).
Args: channel_id: YouTube channel ID max_results: Number of recent videos to fetch (default: 10, max: 50) published_after: ISO date to filter videos published after this date
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | ||
| max_results | No | ||
| published_after | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains parameters and defaults but omits details like error handling, rate limits, or sorting order of results. Acceptable but not comprehensive.
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?
Extremely concise: one line intro, then a clear args list. Every sentence adds value, no 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?
Output schema exists, so return values need not be explained. Description covers inputs and filter. Could mention that results are sorted by publish date (descending) for full clarity, but 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?
Schema description coverage is 0%, yet description adds full meaning for all three parameters: channel_id, max_results (with default and max), and published_after (ISO date). Adds significant value beyond 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?
Clearly states it fetches recent videos from a YouTube channel, including the requirement for a YouTube Data API key. This distinguishes it from sibling tools like 'analyse_video' which perform analysis, not listing.
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?
Mentions the prerequisite of an API key, which is helpful. No explicit when-not or alternatives, but sibling tools are for different tasks, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push analysed content as markdown files to a GitHub repository.
Syncs video analyses, X feed digests, and images to a configured GitHub repo. Use after analyse_video, analyse_x_feed, or generate_image to persist results.
Args: analyses: List of analysis result objects from analyse_video or batch_analyse commit_message: Git commit message (default: 'Add video analyses') image_paths: Optional list of objects with 'analysis' (dict) and 'image_path' (str) fields x_digests: Optional list of X digest analysis objects from analyse_x_feed
| Name | Required | Description | Default |
|---|---|---|---|
| analyses | Yes | ||
| commit_message | No | Add video analyses | |
| image_paths | No | ||
| x_digests | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool pushes markdown files and implies git commits via the commit_message parameter, but does not mention authentication requirements, overwrite semantics, or error handling. More detail is needed for full 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?
The description is two concise paragraphs with no fluff. The first paragraph states purpose and usage timing; the second details parameters. Minor redundancy (first two sentences cover similar ground) keeps it from a 5.
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 moderate complexity (4 params, dependency on other tool outputs) and the existence of an output schema, the description provides a complete usage flow and parameter explanations. It lacks return value details, but the output schema fills that 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?
With 0% schema description coverage, the description carries full burden and succeeds. It defines 'analyses' as results from analyse_video/batch_analyse, explains 'image_paths' structure, and ties 'x_digests' to analyse_x_feed. This adds significant meaning 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 uses specific verbs ('Push', 'Sync') and explicitly states it stores analysis results to a GitHub repo. It clearly distinguishes itself from sibling tools that analyse or generate content.
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 explicitly says 'Use after analyse_video, analyse_x_feed, or generate_image to persist results', providing clear when-to-use guidance and naming alternative actions.
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.14.1analyse_videoanalyse_x_feedbatch_analysegenerate_imagelist_channel_videossync_to_githubScored across 6 tools
Each tool targets a distinct function: single video analysis, batch analysis, X feed analysis, image generation, channel listing, and GitHub sync. No functional overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyse_video, generate_image, sync_to_github), with clear imperative verbs.
Six tools cover the core pipeline steps (input, analysis, visualization, storage) without redundancy. Each tool earns its place for a focused content pipeline server.
The pipeline covers major operations: ingestion (YouTube single/batch, X feed), analysis, infographic generation, and GitHub sync. Missing features like retrieval or deletion of past analyses, but domain is appropriately bounded.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
YouTube transcripts, Instagram profiles and posts, and TikTok data as MCP tools.
Social media analytics, video analysis, and competitor intel for any MCP-compatible AI agent.
Build, run, schedule, and publish AI video pipelines to YouTube and TikTok from any MCP client.
