This server provides an MCP connector for AI assistants to search, browse, and read official Luxembourg government press service (SIP) news articles in German, French, or English, with both keyword and semantic search capabilities.
search_news: Full-text keyword search across the entire SIP archive (back to ~2012), with filters for date range, category, and interface language. Returns newest-first results with title, summary, URL, date, category, and content language.
browse_latest_news: Browse the chronological news feed without a search query, supporting the same date, category, and language filters. Useful for exploring recent items or a specific date range.
get_article: Fetch the full, cleaned body text of a specific article by URL, with a configurable character limit (up to 40,000 chars). Returns body text, summary, word count, category, and content language.
list_categories: Retrieve reference lists of available category keys (e.g. communiques, articles, discours) and supported interface languages for use in other tools.
semantic_search: Meaning-based (vector similarity) search using natural-language questions — finds relevant articles even when exact keywords don't match. Supports filters for date, category, and language, and returns a similarity score per result. Requires the semantic index to be built first.
build_semantic_index: Build or incrementally update the local vector index (ChromaDB/Qdrant) by embedding article titles and summaries via an embedding model (e.g. via OpenRouter). Safe to re-run periodically to index new content.
semantic_index_status: Inspect the current vector index state: item count, date range covered, content languages, embedding model in use, storage location, and API key configuration.
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., "@SIP News MCP Search for recent news about digital innovation in Luxembourg"
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 connector that lets an AI assistant
search and read the official news of the Luxembourg government press service
(Service information et presse, SIP) at
sip.gouvernement.lu.
It exposes the full SIP news archive (press releases, communiqués, speeches, state visits, ministerial news, ~2300 items back to February 2000) as clean, structured, full-text-searchable data, in German, French or English.
The SIP news page loads its list through a JavaScript component, so a naive HTTP fetch returns an empty shell. This connector instead uses the site's own RSS endpoints, which return clean, paginated, newest-first data:
Purpose | Endpoint |
Browse all news |
|
Full-text search |
|
Each page returns 50 items as a sliding window over the whole archive. The connector pages through automatically, de-duplicates, decodes the (double-encoded) entities, recovers each item's category/language/date from its URL, and can fetch the full article body on demand.
Related MCP server: AllNewsAPI MCP
Tool | What it does |
| Keyword full-text search across the whole archive (newest first). |
| Meaning-based (vector) search; handles natural-language questions. |
| The chronological news feed, newest first. |
| Fetch the full, cleaned text of one article by URL. |
| Reference list of category keys and interface languages. |
| (Re)build the local vector index used by |
| Size and coverage of the vector index. |
Common parameters:
language — de, fr or en (interface language; many items are in French
regardless, so try more than one if needed).
limit — how many results to return; larger values page deeper into history.
since / until — YYYY-MM-DD date bounds.
category — e.g. communiques (press releases), articles, discours
(speeches); see list_categories.
Returned fields per item: title, summary, url, published (ISO),
published_human, category, category_label, content_language, source.
search_news / browse_latest_news also return count, complete and an
optional note. complete: false means the scan stopped at the page cap or
time budget rather than covering the whole archive/range, so a short or empty
list there is not an authoritative "nothing exists" (the note explains how
to narrow the query). get_article returns the body and a truncated flag.
semantic_search matches news by meaning rather than exact keywords, so it
answers natural-language questions ("military cooperation with Belgium",
"attacks on state IT systems") even when the wording differs from the article.
How it works:
build_semantic_index pages through the archive, embeds each item
(title + summary) with an embedding model, and stores the vectors in the
configured vector store (ChromaDB by default). For NVIDIA retrieval models
on OpenRouter, documents are embedded as passage and queries as query
(asymmetric retrieval), which sharply improves ranking.
semantic_search embeds the question and returns the nearest items by cosine
similarity, with the same language / category / since / until filters.
Each result carries a similarity score in [0, 1].
Setup:
Get an OpenRouter API key and put it in the
server's environment as OPENROUTER_API_KEY (see the config below). The
default model nvidia/llama-nemotron-embed-vl-1b-v2:free is free. (Or use a
local embedder instead, see below.)
Build the index once (from Claude, call build_semantic_index, or run the
one-liner below). A full build covers the whole archive (~2300 items, back to
in about a minute. Re-run it periodically to pick up new news.
uv run --extra semantic python -c "import asyncio; from sip_news_mcp.semantic import SemanticIndex; print(asyncio.run(SemanticIndex().build(language='fr', max_items=3000)))"Relevant environment variables:
Variable | Purpose |
|
|
| Embedding API key (only for the default OpenRouter provider). |
| Embedding model id (default: the free Nemotron model). |
| Embedding API base; point at a local server for self-hosted embeddings. |
| Embedding key (falls back to |
|
|
|
|
| Chroma index location; local disk only (default under |
See .env.example.
Point SIP_NEWS_EMBED_BASE_URL at any OpenAI-compatible /embeddings server
(Ollama, vLLM, LocalAI, text-embeddings-inference, ...). No OpenRouter key is
needed. For example, with Ollama (ollama pull nomic-embed-text):
SIP_NEWS_EMBED_BASE_URL=http://localhost:11434/v1
SIP_NEWS_EMBED_MODEL=nomic-embed-text
# no key; input_type is auto-disabled for non-OpenRouter endpointsThen build the index. (Changing the embedding model/endpoint changes the vector
space, so rebuild the index with refresh=true when you switch.)
Semantic search is optional. With SIP_NEWS_SEMANTIC=off (or simply by not
installing a vector backend), the server exposes only the four keyword tools
(search_news, browse_latest_news, get_article, list_categories). No
vector database, no embeddings, no OpenRouter key, and none of the heavy
optional dependencies are needed, which makes it the simplest thing to deploy.
The vector-DB dependencies are optional extras, so the base install is lightweight:
Install | What you get |
| Keyword-only (no vector deps). |
| + embedded ChromaDB backend. |
| + Qdrant backend. |
| + both backends. |
With SIP_NEWS_SEMANTIC=auto (the default) the server enables semantic search
only when the configured backend's library is actually installed.
uv (recommended), or Python 3.10+ with pip.
uv will download a suitable Python automatically; you do not need one
installed system-wide.
Note (Windows + network drives). If you keep this project on a network / UNC drive, Python's Windows extensions (
pywin32, pulled in bymcp) cannot load their DLLs from a UNC path, so the virtual environment must sit on a local disk. PointUV_PROJECT_ENVIRONMENTat a local folder (the project code can stay on the network drive; only the installed environment needs to be local). The commands and MCP config below set it.
cd C:\path\to\SIP-MCP-Connector
$env:UV_PROJECT_ENVIRONMENT = "$env:LOCALAPPDATA\sip-news-mcp\venv"
uv sync --extra semantic --extra dev # LOCAL env with semantic + test deps
uv run --extra dev pytest # run the offline test suite
uv run --extra semantic sip-news-mcp # start the server (stdio, with semantic)
# For a keyword-only server, drop the extras: uv run sip-news-mcpA quick live check without an MCP client (run in the same shell, so it reuses the local environment set above):
uv run python -c "import asyncio; from sip_news_mcp.client import SipNewsClient; print(asyncio.run(SipNewsClient().search('cyber', language='de', limit=3)))"Add this to claude_desktop_config.json
(%APPDATA%\Claude\claude_desktop_config.json on Windows), then restart Claude
Desktop. See examples/claude_desktop_config.json:
{
"mcpServers": {
"sip-news": {
"command": "uv",
"args": ["--directory", "C:\\path\\to\\SIP-MCP-Connector", "run", "--extra", "semantic", "sip-news-mcp"],
"env": {
"UV_PROJECT_ENVIRONMENT": "C:\\sip-news-mcp\\venv",
"OPENROUTER_API_KEY": "sk-or-v1-...your key...",
"SIP_NEWS_CHROMA_DIR": "C:\\sip-news-mcp\\chroma"
}
}
}
}(--extra semantic and the OPENROUTER_API_KEY / SIP_NEWS_CHROMA_DIR env are
only needed for semantic search; for a keyword-only server drop them. If Claude
Desktop cannot find uv, use the absolute path to uv.exe, since it may not
inherit your shell PATH.)
claude mcp add sip-news `
--env UV_PROJECT_ENVIRONMENT="$env:LOCALAPPDATA\sip-news-mcp\venv" `
--env OPENROUTER_API_KEY="sk-or-v1-...your key..." `
-- uv --directory "C:\path\to\SIP-MCP-Connector" run --extra semantic sip-news-mcp"Search SIP for news about cybersécurité in 2025 and summarise the top 5."
"List all SIP press releases (communiques) since 2026-01-01."
"Find SIP articles mentioning armée and open the most recent one in full."
Search uses the SIP site's own full-text engine, which is a broad match: a
hit may mention the term only in its body, and ranking is the site's, not
ours. The connector returns those results faithfully. Use get_article to
confirm relevance before quoting.
Content language varies per item; the connector reports content_language
per result so you can tell French items from German ones.
Date filtering is most efficient for recent ranges (the feed is newest-first
and stops early once it passes since); very old ranges page deeper and may
hit the page cap or the ~45s time budget, in which case the result is marked
complete: false with an explanatory note.
Identical requests are cached in-process for 5 minutes (bounded LRU), so repeating the same query does not re-hit the server. A single search/browse call still issues up to ~40 sequential page requests, but they are made one at a time (each awaited before the next) under a descriptive User-Agent, which keeps load on the public government server modest.
get_article only fetches https URLs on sip.gouvernement.lu (host is
parsed and checked, not substring-matched), so it cannot be turned into a
request to other hosts.
This connector only reads public pages; it performs no writes and needs no credentials.
The server speaks two transports, chosen by MCP_TRANSPORT:
stdio (default) for Claude Desktop / Code (local subprocess).
http (streamable-http) for containers and Kubernetes, listening on
MCP_HOST:MCP_PORT (default 0.0.0.0:8000, path /mcp).
It also supports two vector backends via SIP_NEWS_VECTOR_BACKEND:
chroma (embedded, default) for local use.
qdrant (a shared, network Qdrant) for containers / multiple replicas, set
with QDRANT_URL (and optional QDRANT_API_KEY).
Brings up Qdrant + the MCP server (HTTP) together:
echo "OPENROUTER_API_KEY=sk-or-v1-...your key..." > .env
docker compose up -d --build
docker compose run --rm index-build # populate the vector index once
# MCP server: http://localhost:8000/mcp (streamable-http)The simplest deployment: no Qdrant, no embeddings, no API key. Just the four keyword tools.
docker compose -f docker-compose.minimal.yml up -d --build
# MCP server on http://localhost:8000/mcpThe minimal image is built with no vector-DB dependencies
(docker build --build-arg EXTRAS="" -t sip-news-mcp:minimal .) and runs with
SIP_NEWS_SEMANTIC=off.
docker build -t sip-news-mcp:latest . # full (RAG) image
docker run --rm -p 8000:8000 \
-e OPENROUTER_API_KEY=sk-or-v1-... \
-e SIP_NEWS_VECTOR_BACKEND=qdrant -e QDRANT_URL=http://host.docker.internal:6333 \
sip-news-mcp:latestThe chart in deploy/helm/sip-news-mcp deploys the
server, a bundled Qdrant (StatefulSet + PVC), a Secret for the API key, and an
optional one-shot Job that builds the index after install.
helm install sip-news deploy/helm/sip-news-mcp \
--set openrouter.apiKey=sk-or-v1-...your key...
# or reference an existing Secret: --set openrouter.existingSecret=my-secretFor a keyword-only deployment (just a Deployment + Service, no Qdrant, Secret or
Job), set semantic.enabled=false:
helm install sip-news deploy/helm/sip-news-mcp --set semantic.enabled=falseKey values (see values.yaml):
Value | Default | Purpose |
|
| Set |
|
|
|
|
| Deploy a bundled Qdrant; set |
|
| API key (creates a Secret), or use |
|
| Run a post-install Job to populate the index (qdrant backend). |
|
| Expose via an Ingress. |
|
| Scale out (qdrant backend; keep |
Reach it with kubectl port-forward svc/sip-news-... 8000:8000, then point an
MCP client at http://localhost:8000/mcp.
Claude Desktop's config is stdio-only; to use the HTTP server, configure an
MCP client that supports the streamable-http transport with URL
http://<host>:8000/mcp.
src/sip_news_mcp/
client.py HTTP client, RSS/article parsers, filtering, pagination
semantic.py OpenRouter embeddings + the SemanticIndex
vectorstore.py pluggable vector backends (ChromaDB / Qdrant)
build_index.py `sip-news-index` CLI (one-shot index build, used by jobs)
server.py FastMCP server, tool definitions, stdio/http transport
__main__.py `python -m sip_news_mcp`
tests/
test_urls.py URL / host / selector-metadata tests
test_parsing.py RSS feed + article parser tests
test_client.py SipNewsClient pagination / filtering tests
test_semantic.py vector layer tests (fake embedder)
test_server_config.py semantic on/off/auto config logic
test_server_tools.py MCP tool registration / integration (each tool >=2x)
conftest.py shared fixtures; fixtures/ captured live responses
Dockerfile container image (HTTP transport)
docker-compose.yml Qdrant + MCP server + one-shot index build
deploy/helm/sip-news-mcp/ Kubernetes Helm chart
examples/
claude_desktop_config.jsonBrowse the latest SIP news, newest first (no search query needed).
This is the chronological feed of everything the press service publishes.
Combine with `since`/`until` to get all news in a date range, or with
`category` to follow only press releases, speeches, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Interface language: de, fr or en. | de |
| limit | No | Maximum number of items (1-200). | |
| since | No | Only items on/after this date (YYYY-MM-DD). | |
| until | No | Only items on/before this date (YYYY-MM-DD). | |
| category | No | Restrict to a category key (see list_categories). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: the feed is chronological and newest first, and it is a contextual browse (no search required). It does not mention pagination or authentication, but these are standard for a read-only list tool and output schema exists.
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 sentences, front-loaded with the primary purpose, followed by usage details. Every sentence adds value without redundancy or wordiness.
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 low complexity, full parameter coverage, and presence of an output schema, the description is complete. It covers the main use case, suggests parameter combinations, and references a sibling tool (list_categories) for further context.
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 schema covers all parameters with clear descriptions (e.g., language de/fr/en, limit 1-200, since/until format, category referencing list_categories). The description adds value by emphasizing the chronological nature and the 'no search query' point, and by recommending combination with other parameters.
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 purpose: 'Browse the latest SIP news, newest first (no search query needed).' It specifies the verb (browse), resource (SIP news), and ordering, distinguishing it from sibling tool 'search_news' which requires a query.
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 advises to combine with 'since'/'until' for date ranges and 'category' for filtering, providing clear usage patterns. It also states no search query is needed, but does not explicitly exclude cases where search_news would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or update the local vector index that powers semantic_search.
Pages through the most recent SIP news, embeds each item (title + summary)
via OpenRouter, and stores the vectors in a local ChromaDB collection. Safe
to run repeatedly: by default it only embeds items not already indexed. Run
it once before using semantic_search, and again periodically to pick up new
news. This call fetches from SIP and the embedding API, so it can take a
little while for large `max_items`.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Interface language to pull news from: de, fr or en. | de |
| max_items | No | How many recent items to (re)index (1-2000). | |
| refresh | No | Re-embed items already in the index instead of skipping them. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool pages through SIP news, embeds via OpenRouter, stores vectors in ChromaDB, is safe to run repeatedly (only indexes new items by default), and that it can take time for large max_items. This covers key 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 concise (four sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, process, safety/repeatability, and performance characteristic. 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 the tool's complexity (external API calls, indexing process), the description explains the essential steps and context. The existence of an output schema (not shown but indicated) means return values are documented elsewhere. The description is sufficiently complete for an agent to understand when and how to use the 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%, so baseline is 3. The description does not add meaning beyond the schema for parameters: language, max_items, refresh. The schema itself already describes them clearly. The description provides context about how they are used in the process, but no new semantic details.
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: 'Build or update the local vector index that powers semantic_search.' It uses specific verbs (build/update) and identifies the resource (local vector index). This distinctly differentiates it from sibling tools like browse_latest_news, get_article, or semantic_search.
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 usage guidance: 'Run it once before using semantic_search, and again periodically to pick up new news.' It also notes the tool is safe to run repeatedly and describes default behavior. While it does not mention alternatives or when not to use it, the guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and return the full, cleaned text of a single SIP article.
Returns the title, an optional summary, the body text (whitespace cleaned, markup removed), a word count, the category and the content language.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The article URL returned by search_news or browse_latest_news. | |
| max_chars | No | Maximum characters of body text to return (truncated cleanly). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently describes the returned fields (title, summary, body, word count, category, language) and processing details (whitespace cleaned, markup removed). It also mentions truncation behavior via max_chars. No destructive actions are implied, so this is adequate.
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. Two sentences: one states the purpose, the other lists returned fields. No wasted words, no redundancy with the schema.
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 that an output schema exists (not shown but indicated), the description need not detail return types. It covers the main return fields and the max_chars parameter behavior. It could mention error handling (e.g., invalid URL) but overall it's fairly complete for a straightforward fetch 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 100%, so the schema already documents both parameters. The description adds minimal context: 'url' should come from search_news/browse_latest_news, and 'max_chars' has default 8000, max 40000, min 200, and truncates cleanly. This adds some value but is not essential 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 'Fetch and return the full, cleaned text of a single SIP article.' It uses specific verbs (fetch, return) and resource (single SIP article), and distinguishes it from sibling tools like search_news and browse_latest_news which are for finding articles, not retrieving full 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 implies usage after finding an article via search_news or browse_latest_news, but it does not explicitly state when to use it vs. alternatives, nor does it provide when-not-to-use guidance or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the content categories and interface languages understood by the SIP site.
Use the returned category keys with the `category` parameter of
search_news / browse_latest_news.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It transparently describes the tool as a listing operation with no side effects. While it omits details like data freshness or authorization, for a simple read-only tool with no parameters the description is sufficiently 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?
The description is concise with two sentences, front-loading the purpose and immediately providing usage guidance. Every sentence adds value without extraneous 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 low complexity (no parameters) and the presence of an output schema, the description completely covers what the tool does and how the output should be used with sibling tools, making it fully actionable 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?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, but it does provide context on the output's usage, which adds value beyond the empty 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 that the tool lists content categories and interface languages, using specific verb ('List') and resource ('content categories and interface languages'). It further distinguishes itself by explaining how the output is used with sibling tools search_news and browse_latest_news.
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 instructs the agent to use the returned category keys with the `category` parameter of search_news / browse_latest_news, providing clear context on when to use this tool—essentially a prerequisite step for those tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across the entire SIP news archive (back to ~2012).
Results are returned newest-first. Each result has a title, a short
summary, the publication date, the content language, the category and a
URL. Use get_article on a URL to read the full text.
The connector pages through the site automatically until it has `limit`
matching items or the archive is exhausted, so a larger `limit` simply
digs deeper into history.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Words or phrase to search for, e.g. 'cybersécurité' or 'défense'. | |
| language | No | Interface language: de, fr or en. | de |
| limit | No | Maximum number of results (1-200). | |
| since | No | Only items on/after this date (YYYY-MM-DD). | |
| until | No | Only items on/before this date (YYYY-MM-DD). | |
| category | No | Restrict to a category key (see list_categories), e.g. 'communiques'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: results are newest-first, automatic pagination until limit or archive exhausted, and each result includes title, summary, date, language, category, and URL. No destructive or rate-limiting details are needed, as it's a read-only search tool. The description is transparent and accurate.
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 short paragraphs, no fluff. First paragraph explains purpose and result fields, second explains pagination. Every sentence adds value, and the structure is logical and front-loaded with the key purpose.
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 output schema and full schema documentation, the description is nearly complete. It covers search scope, ordering, result fields, pagination, and cross-reference to get_article. One minor gap: it doesn't specify whether the search includes article bodies or just titles, but 'full-text search' implies body content. Otherwise, comprehensive.
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 some extra context: for 'query' it provides examples, for 'limit' it explains that larger values dig deeper into history. However, most parameter descriptions in the schema are already clear, and the description does not significantly enhance understanding beyond what is already in 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 it performs full-text search across the SIP news archive, with a specific verb ('search'), resource ('news archive'), and scope ('back to ~2012'). It distinguishes itself from siblings like browse_latest_news (browsing without search) and get_article (retrieving full text).
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 general guidance (results newest-first, pagination behavior) and cross-references get_article for full text, but it does not explicitly state when to use this tool versus alternatives like browse_latest_news or semantic_search. No 'when not to use' or direct comparison with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the size and coverage of the semantic (vector) index.
Returns how many items are indexed, the date range and content languages covered, the embedding model, the on-disk location, and whether an OpenRouter API key is configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states what the tool returns but does not mention that it is read-only, has no side effects, or any rate limits/permissions required.
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 establishes the core action, second lists details. No fluff, front-loaded, easy to parse.
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 output schema exists, description does not need to detail return structure. Already lists key outputs comprehensively. Tool is simple (no params), so description is 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?
No parameters exist, schema coverage is 100%. Description adds no parameter info because none needed, but it is not a deficiency. Baseline for 0 params is 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?
Clearly states it reports the size/coverage of the semantic index. Lists specific outputs (items indexed, date range, languages, model, location, API key status). Differentiates from sibling 'build_semantic_index' which is about building, not status.
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 purpose implies checking status, and the sibling 'build_semantic_index' suggests the alternative. However, there is no explicit guidance on when to use this vs other tools (e.g., checking before building).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Meaning-based search over the SIP news index (vector similarity).
Unlike search_news (exact keywords), this matches by meaning, so it handles
natural-language questions and wording that differs from the article. Each
result includes a `similarity` score in [0, 1].
Set `top_k` to control how many results come back (default 10). Requires the
index to have been built with build_semantic_index and an OPENROUTER_API_KEY
in the server environment. If the index is empty or the key is missing, the
response says so.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A natural-language question or topic, e.g. 'military cooperation with Belgium'. | |
| top_k | No | How many of the most relevant results to return (1-50). | |
| language | No | Restrict to one content language: de, fr or en. | |
| since | No | Only items on/after this date (YYYY-MM-DD). | |
| until | No | Only items on/before this date (YYYY-MM-DD). | |
| category | No | Restrict to a category key (see list_categories). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully discloses behavior: vector similarity, similarity score range, top_k control, prerequisites, and error messaging for missing index or key.
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; two short paragraphs front-loading purpose, then key details. Every sentence is necessary and well-ordered.
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 output schema exists (so return format not needed), description covers prerequisites, error handling, parameter usage, and distinguishes from 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?
Schema coverage is 100%, baseline 3, but description adds value by contextualizing 'query' as natural-language questions and clarifying 'top_k' defaults and purpose 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 performs 'meaning-based search over the SIP news index' with vector similarity, and explicitly distinguishes it from the keyword-based sibling 'search_news'.
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 guidance by contrasting with search_news, explains prerequisites (build_semantic_index and OPENROUTER_API_KEY), and describes error behavior when conditions not met.
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.0browse_latest_newsbuild_semantic_indexget_articlelist_categoriessearch_newssemantic_index_statussemantic_searchEach tool has a clearly distinct purpose: browsing chronological feed, keyword search, semantic search, fetching articles, listing categories, and index management are all well-separated. Descriptions explicitly clarify differences (e.g., search vs. semantic_search).
Most tool names follow a verb_noun snake_case pattern (browse_latest_news, get_article, list_categories, search_news, build_semantic_index). However, 'semantic_index_status' and 'semantic_search' are noun phrases without a verb, breaking the pattern and introducing inconsistency.
With 7 tools, the server is well-scoped. It covers all core functionalities for a news archive (browsing, searching, retrieving, and managing the semantic index) without unnecessary bloat.
The tool surface is nearly complete for a read-only news server: both chronological and full-text search, plus semantic search, article retrieval, and index management. A minor gap is the lack of a dedicated 'get_article_by_id' tool, but URLs serve as identifiers.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Keyless MCP access to official Luxembourg public data: laws, statistics, mobility, and more.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Cross-source news, finance, AI and tech search across 29 sources for agents (BBC, NYT, CNBC, HF).
AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/masterries/SIP-MCP-Connector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
