Integrates with a local Ollama server to generate LLM-written digests with key facts, trends, and impact analysis, keeping article summarization on the local network.
Consumes and caches RSS feeds, enabling tools to list sources, fetch latest articles, search titles and summaries, and generate categorized news views from configured feeds.
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., "@veille-mcp What happened in AI this week? Give me a digest focused on European cloud providers."
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.
An MCP server that turns a curated set of RSS feeds into a Data, AI and cloud tech watch any MCP client can use (Claude Code, Claude Desktop, Cursor…), with digests written by a local LLM served by Ollama: no article leaves the network to be summarised.
It runs in my home lab, in a Proxmox LXC container, next to the Ollama server.
Claude Code ──MCP / Streamable HTTP──▶ veille-mcp (LXC) ──▶ 16 RSS feeds
│
└──▶ Ollama qwen3:8b (LXC, local LLM)Kind | Name | Purpose |
Tool |
| Newest articles from the last n hours, filtered by category ( |
Tool |
| Keyword search over titles and summaries, title matches ranked first |
Tool |
| Summary written by the local LLM: key facts with numbered citations, trends, impact for a European cloud provider |
Tool |
| Feeds being watched |
Resource |
| Feed configuration as JSON |
Prompt |
| Ready-made competitive brief on a vendor (AWS, Scaleway, Google Cloud…) |
Tools return typed, structured output (Pydantic models) and are annotated read-only. Feeds are fetched concurrently and cached for 15 minutes; a failing feed is reported in unavailable_sources instead of breaking the call.
Default feeds cover AI labs and research (Hugging Face, OpenAI, Google AI, Simon Willison, The Decoder, MIT Technology Review…), data engineering (InfoQ, Databricks) and cloud vendors (OVHcloud, Scaleway, AWS, Google Cloud, Azure). Point VEILLE_SOURCES at your own JSON file to change them.
Related MCP server: rss-digest-mcp
pip install -e .
veille-mcp # stdio, for a local client
OLLAMA_URL=http://localhost:11434 veille-mcp --transport streamable-http --host 0.0.0.0Add it to Claude Code:
claude mcp add --transport http veille http://<host>:8000/mcpThen just ask: "What happened in AI this week? Give me a digest focused on European cloud providers."
Variable | Default | |
| (unset) | Ollama endpoint; |
|
| Any model pulled in Ollama |
| (unset) | Comma-separated |
| bundled list | Path to a JSON feed list |
|
| Feed cache, in seconds |
digest runs on CPU in my lab and takes a few minutes; raise the client timeout if needed (MCP_TOOL_TIMEOUT=600000 for Claude Code).
tar --exclude=.venv --exclude=.git -czf - . | ssh root@<ct> 'mkdir -p /opt/veille-mcp && tar -xzf - -C /opt/veille-mcp && /opt/veille-mcp/deploy/install.sh'deploy/install.sh creates a dedicated system user, a virtualenv and a hardened systemd unit (ProtectSystem=strict, NoNewPrivileges). Settings live in /etc/veille-mcp.env.
pip install -e ".[dev]"
ruff check . && pytest --covTests run the server in-process through the MCP client, with mocked HTTP for feeds and Ollama. CI runs lint and tests on Python 3.12 and 3.13.
MIT
Synthèse rédigée par le LLM local (Ollama) des articles récents.
focus : angle de lecture facultatif, ex. "concurrence des clouds européens". La génération peut prendre plusieurs minutes sur CPU.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | ||
| hours | No | ||
| limit | No | ||
| category | No | ||
| language | No | fr |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds material context beyond them: the digest is generated locally by Ollama and generation can take several minutes on CPU. That latency warning is genuinely useful for an agent deciding whether to call it, though failure/length behavior is not covered.
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?
Front-loads the purpose in one sentence, then the parameter note and the latency caveat. Compact and free of filler, though the terse fragments leave gaps rather than waste.
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?
An output schema exists, so return values need not be explained, but with 5 optional parameters at 0% coverage and no guidance on when this synthesis is preferable to latest_news or search_news, the definition is under-specified for the tool's complexity and multi-minute cost.
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% across 5 parameters, so the description carries the full burden, yet it explains only 'focus' (optional reading angle with an example). hours, limit, category, and language are left entirely undocumented in both schema and description.
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?
States a specific output (a synthesis of recent articles) produced by the local Ollama LLM, which distinguishes it from the retrieval-oriented siblings list_sources/latest_news/search_news. It does not name those siblings explicitly, so the differentiation is implied rather than stated.
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?
Usage is only implied: the tool produces a written digest, and the focus example hints at a topical angle. There is no explicit when-to-use versus the sibling news/search tools and no stated exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Articles publiés ces dernières heures, du plus récent au plus ancien.
category : ia, data ou cloud. source : nom (ou partie du nom) d'un flux, ex. "OVHcloud".
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| limit | No | ||
| source | No | ||
| refresh | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| articles | Yes | |
| unavailable_sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-source behavior are covered. The description usefully adds the freshness window and sort order, but says nothing about what the 'refresh' flag actually does or whether results are cached.
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?
Very short and front-loaded: the core behavior leads, then the parameter hints follow. The trailing parameter notes read a bit like a fragmented addendum but nothing is wasted.
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?
An output schema exists, so return values need no explanation, but with five parameters at 0% schema coverage the description covers only two of them and offers no guidance on defaults or the refresh behavior, leaving gaps for an agent invoking it.
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 carry the load. It does add real value by enumerating category values (ia, data, cloud) that the schema lacks as enums, and by explaining source as a feed name or partial name with an example, but hours, limit, and refresh remain completely undocumented.
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?
States a concrete resource and scope: articles published in the last few hours, ordered newest to oldest. The recency/ordering framing distinguishes it in spirit from search_news and digest, but it never names a sibling to make the boundary explicit.
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 'dernières heures / du plus récent au plus ancien' framing implies this is the feed-style tool to use when freshness matters, but there is no explicit when-to-use, when-not-to-use, or alternative named against search_news or digest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les flux suivis. category : ia, data ou cloud.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond 'flux suivis' — nothing about whether these are the user's own subscriptions, whether the list can be empty, or how results are ordered.
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 short telegraphic clauses, purpose first, with no filler. The parameter note is compressed to the point of missing a verb, which costs a little clarity but wastes nothing.
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?
An output schema exists, so return values need not be described, and the single optional parameter is covered. What is missing is the meaning of the empty/null category default and confirmation that these are followed sources rather than a global catalog — small but real gaps for an otherwise 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 description coverage is 0% and the schema only declares an untyped nullable string, so the description carries the real burden. It supplies the three legal values ('ia, data ou cloud'), which the schema omits entirely — a genuine addition — but it does not explain the null/default case (omitting it presumably returns all sources).
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 states a specific verb and resource ('Liste les flux suivis' — lists the tracked feeds), which is clearly distinct from siblings like latest_news and search_news that return content rather than the source catalog. It does not, however, explicitly contrast itself with any sibling, so it stops short of a 5.
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?
There is no guidance on when to call this versus latest_news, search_news or digest, nor any prerequisite or exclusion. The mention of a category value is a parameter detail, not usage direction, so an agent must infer the routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche par mots-clés dans les titres et résumés (fenêtre par défaut : 7 jours).
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| limit | No | ||
| query | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| articles | Yes | |
| unavailable_sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the searched fields (titles and summaries) and the 7-day default window, but duplicates the schema default (hours=168) and says nothing about pagination or result caps.
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 compact sentence with the primary action front-loaded and no filler. It is efficient, though the terseness leaves room for useful detail that was omitted rather than a structural flaw.
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?
An output schema exists, so return values need not be described. Still, for a 4-parameter search tool with 0% schema coverage, the missing semantics of category (what values are valid?) and limit leave the definition only 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 description coverage is 0%, so the description must compensate; it clarifies what "query" matches against and restates the default window that the schema already encodes as hours=168. The limit and category parameters remain completely unexplained in both places.
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 states a specific verb ("Recherche") and resource (news titles and summaries), plus the searched fields, so the agent knows exactly what it does. It does not, however, distinguish itself from the sibling latest_news, which likely performs a similar retrieval.
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?
There is no when-to-use guidance, no exclusions, and no reference to the alternatives (latest_news, digest, list_sources). The keyword-search framing implies usage but leaves the agent to infer when this tool beats its siblings.
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.1.0digestlatest_newslist_sourcessearch_newsScored across 4 tools
Each tool has a fairly distinct role: listing feeds, fetching the most recent articles, keyword search, and LLM synthesis. The main overlap is between latest_news and search_news, which both return articles, but the descriptions clearly differentiate them by time window versus keyword matching.
list_sources and search_news follow a clear verb_noun snake_case pattern, but latest_news is adjective_noun and digest is a bare noun, breaking the convention. The set remains readable, but the pattern is not fully predictable.
Four tools is a reasonable scope for a read-only news monitoring server, covering discovery, browsing, searching, and summarization. It is slightly thin in that there is no tool for source management or fetching a single article, but nothing feels redundant.
The core read workflows of a veille tool are covered: list sources, get latest, search, and produce a digest. Minor gaps exist, such as retrieving full article content or managing/filtering sources, but an agent can work around these for typical monitoring tasks.
Verified business OSS MCP for search, RSS, crawling, documents, browser, media and transcription.
Narrative intelligence from thousands of curated media sources, delivered to AI through MCP.
Your curated sources (RSS, YouTube, podcasts, Google News) as context for any AI agent.
Summarize URLs, repurpose content, daily news digests, find competitors. Cost telemetry built in.
