Skip to main content
Glama
Jakolo121

German Newsfeed MCP Server

by Jakolo121
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

German Newsfeed MCP Server

pylint tests python license

Disclaimer: This is a private, unofficial project. It is not an ARD product and is neither operated nor endorsed by ARD, ARD-aktuell, or NDR. It is developed independently of the author's professional employment. "ARD" and "tagesschau" are trademarks of their respective owners and are named here solely to describe the API being accessed.

This project merely connects the public API to an MCP-capable AI assistant. ARD-aktuell is responsible for the API itself, its operation, and its content; this project cannot provide information on any of those. Please raise any concerns about this project, in particular from rights holders, as a GitHub issue. Substantiated concerns will be addressed promptly.

In thirty seconds

This Model Context Protocol (MCP) server connects your AI assistant (Claude Desktop and others) to the public news API of tagesschau.de: current headlines, category and regional news, and full-text search, locally via stdio, no API key required.

Example: asked "Was sind die aktuellen Schlagzeilen?", the assistant answers with the current top stories from tagesschau.de, each with title, date, summary, and a link to the article.

Language:

  1. What is this?

  2. Data Source and Terms of Use

  3. Features

  4. Project Structure

  5. Quick Start Local (Claude Desktop)

  6. Remote / Docker Deployment

  7. Configuration Reference

  8. Available Tools

  9. Available Resources

  10. Development Guide

  11. Running the Tests

  12. Makefile Reference

  13. Troubleshooting

  14. When it stops working

  15. License & Acknowledgements

Related MCP server: news-monitor-mcp

What is this?

This MCP server connects the public news API of tagesschau.de to your AI assistant (Claude, Open Claw, etc.).

Once connected, your AI can answer questions like:

  • "Was sind die aktuellen Schlagzeilen?"

  • "Zeig mir die neuesten Wirtschaftsnachrichten."

  • "Suche nach Artikeln über Ukraine."

  • "Welche Regionalnachrichten gibt es aus Bayern?"

For details on the API and its terms, see Data Source and Terms of Use. No API key required.

Data Source and Terms of Use

This server calls the publicly accessible endpoint www.tagesschau.de/api2u/, operated by ARD-aktuell. The delivered content originates from the ARD broadcasters, remains subject to their rights and to the terms of use of tagesschau.de: https://www.tagesschau.de/nutzungsbedingungen/

The API is not officially documented. Community documentation is available at bund.dev (https://tagesschau.api.bund.dev). bund.dev is a civil-society documentation project, neither the operator of the API nor a rights holder of the content. Its documentation served as a reference for this project but does not grant any usage rights.

Applicable limits: at most 60 requests per hour, and no republication of the content except for offerings under a CC licence (https://tagesschau.de/creativecommons). Compliance is the responsibility of whoever operates a given instance.

The robots.txt of tagesschau.de additionally declares an express reservation of rights under Section 44b(3) of the German Copyright Act (as of 2026-05-19): text and data mining and the automated use of the content for training or fine-tuning AI models are prohibited without written consent. Expressly exempt is automated access for the sole purpose of retrieval-augmented generation (RAG) or grounding, provided the technical directives of the robots.txt are complied with and the content remains attributed to its original source. This server falls under that exemption: it passes content to the assistant exclusively together with source links. The retrieved content must not be used to train AI models.

Features

🗞️ Live news

Fetches breaking news, categorised news, and regional news in real time

🔍 Full-text search

Search across all available articles

📺 Live streams

List all available channels and HLS stream URLs

⏱️ Rate limiter

Local token bucket honouring the API's 60/h limit

🚀 Dual transport

stdio for local Claude Desktop; streamable-http for remote / Docker

🐳 Docker-ready

Multi-stage image, non-root user, health-check, resource limits

✅ 273 tests

251 unit tests + 22 live integration tests

🛠️ Makefile

make test, make lint, make docker-build and more

🔒 No secrets

Public API, no API keys

Project Structure

german-newsfeed-mcp/
├── src/
│   └── german_newsfeed_mcp/
│       ├── __init__.py      # Package metadata
│       ├── config.py        # Environment-driven configuration
│       ├── client.py        # Async HTTP client (httpx) + error handling
│       ├── rate_limiter.py  # Token-bucket rate limiter
│       ├── validators.py    # Domain constants + validation helpers
│       ├── formatters.py    # Markdown rendering of news items & channels
│       ├── tools.py         # MCP tool business logic
│       ├── resources.py     # MCP resource business logic
│       └── server.py        # Composition root: FastMCP + run() entry-point
├── tests/
│   ├── conftest.py          # Shared fixtures & mock payloads
│   ├── test_client.py       # Client unit + live integration tests
│   ├── test_rate_limiter.py # Rate-limiter unit tests
│   ├── test_validators.py   # Validator unit tests (URL & ressort checks)
│   ├── test_formatters.py   # Formatter unit tests (pure functions)
│   ├── test_tools.py        # Tool unit + live integration tests
│   └── test_resources.py    # Resource unit + live integration tests
├── main.py                  # Thin entry-point (calls server.run())
├── pyproject.toml           # Project metadata, deps, pytest & pylint config
├── uv.lock                  # Locked dependency graph (commit this!)
├── Dockerfile               # Multi-stage production image
├── docker-compose.yml       # One-command remote deployment
├── .env.example             # Configuration template
├── Makefile                 # Developer shortcuts (test, lint, docker, clean)
├── CHANGELOG.md             # Version history
├── CONTRIBUTING.md          # How to contribute
└── README_de.md             # German version of this file

Quick Start Local (Claude Desktop)

Also applicable to other AI assistants, edit their respective config instead. This mode uses stdio transport; the server is launched as a child process. No port is needed.

Prerequisites

Step 1: Clone and install

git clone https://github.com/Jakolo121/german-newsfeed-mcp.git
cd german-newsfeed-mcp
uv sync

Step 2: Verify it works

uv run python -c "from german_newsfeed_mcp.server import mcp; print('OK!', mcp.name)"
# Expected: OK! German Newsfeed MCP

Step 3: Connect Claude Desktop

Open your Claude Desktop config file:

OS

Path

macOS

~/Library/Application Support/Claude/claude_desktop_config.json

Windows

%APPDATA%\Claude\claude_desktop_config.json

Linux

~/.config/Claude/claude_desktop_config.json

Add the following entry (adjust the path to your clone):

    "german-newsfeed": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/german-newsfeed-mcp",
        "run",
        "german-newsfeed-mcp"
      ]
    },

Step 4: Restart Claude Desktop

Quit and reopen the application, or reload its MCP servers, depending on the application.

Step 5: Try it!

Ask your assistant:

"Was sind die aktuellen Nachrichten?"

Remote / Docker Deployment

Self-hosting for your own or team-internal use. The recommended default is stdio (see Quick Start); the streamable-http transport is an option you choose deliberately.

Security note: The HTTP transport has no authentication. Do not expose it publicly without an authentication layer in front (e.g. a reverse proxy). The Compose setup therefore deliberately binds the port to 127.0.0.1 only. Whoever makes an instance reachable for third parties becomes the responsible operator under the terms of use.

Rate limiter limitations: stateless_http=True refers to MCP sessions, not to the rate limiter. The token bucket is process-local in-memory state. Two limitations follow:

  1. Multiple replicas against the same upstream API multiply the request budget.

  2. A container restart resets the bucket to full. Combined with restart: unless-stopped and a crash loop, this can exceed the limit. Watch the logs.

(The legacy sse transport is still supported.)

Prerequisites

Step 1: Create your .env file

cp .env.example .env
# Edit .env if you want a different port or log level

Step 2: Build and start

docker compose up --build -d

Or:

make docker-build
make docker-run

The server starts at http://localhost:8000.

Step 3: Verify health

docker compose logs german-newsfeed-mcp
docker compose ps

Or:

make docker-logs

Step 4: Connect Claude Desktop (Streamable HTTP)

    "german-newsfeed": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:8000/mcp"]
    },

For external servers: put an authentication layer in front first (see the security note above), then adjust the loopback binding in docker-compose.yml and replace localhost with your proxy's address.

Stop / Update

docker compose down
docker compose up --build -d

Configuration Reference

All settings are read from environment variables (or a .env file).

Variable

Default

Description

TRANSPORT

stdio

stdio or streamable-http (sse legacy)

HOST

0.0.0.0

Bind address (HTTP transports only)

PORT

4200

HTTP port (HTTP transports only)

LOG_LEVEL

INFO

DEBUG, INFO, WARNING, ERROR

RATE_LIMIT_PER_HOUR

60

Local request budget per hour towards the upstream API

USER_AGENT_CONTACT

—

Optional: contact info in the User-Agent header; omitted when unset

The defaults apply when running directly (uv run german-newsfeed-mcp). The Compose setup overrides them: it sets HOST=0.0.0.0 and PORT=8000 (see docker-compose.yml).

Available Tools

These tools are callable by your AI assistant.

get_latest_news

Get the top stories.

Returns the full article text for each item (homepage feed). Every item also carries a 🔗 Volltext: link that get_article accepts.

Parameter

Type

Default

Description

limit

int

10

Max items to return

get_article

Get the complete text of a single article.

Takes the 🔗 Volltext: link printed with every item by get_latest_news, get_news_by_ressort and get_regional_news; a plain https://www.tagesschau.de/<path>.html article link works too.

Parameter

Type

Default

Description

url

str

—

Article link shown in a news listing

Costs exactly one upstream request per call out of the 60/h budget — call it for the articles that matter, not for every headline in a listing.

search_news results carry no article link and cannot be passed to get_article. Locate the article via get_latest_news, get_news_by_ressort or get_regional_news first.

get_news_by_ressort

Filter news by category.

Returns metadata only — title, topline, date and a teaser sentence — no full article text. Every item carries a 🔗 Volltext: link that get_article resolves into the full text.

Parameter

Type

Default

Description

ressort

str

—

inland ausland wirtschaft sport video investigativ wissen

limit

int

10

Max items to return

Ressort strings are automatically normalised to lowercase: "Inland", "INLAND" and "inland" are all equivalent.

get_regional_news

News from a specific German state.

Returns metadata only — title, topline, date and a teaser sentence — no full article text. Every item carries a 🔗 Volltext: link that get_article resolves into the full text; because regional items originate at an ARD state broadcaster, they additionally carry a 📰 Quelle: line naming that broadcaster.

Parameter

Type

Default

Description

region_id

int

—

1=BW · 2=BY · 3=BE · 4=BB · 5=HB · 6=HH · 7=HE · 8=MV · 9=NI · 10=NW · 11=RP · 12=SL · 13=SN · 14=ST · 15=SH · 16=TH

ressort

str

None

Optional category filter

limit

int

10

Max items to return

search_news

Full-text search across all available articles.

Returns metadata only — title, date and article type — no full article text. Search results carry no article link and therefore cannot be passed to get_article.

Parameter

Type

Default

Description

search_text

str

—

Search query

page_size

int

10

Results per page (max 30)

result_page

int

0

Page offset (0-based)

get_channels

List all live channels with stream URLs.

(No parameters)

Available Resources

Resources are addressable URIs that MCP clients can read directly.

URI

Description

news://tagesschau/homepage

Homepage top stories

news://tagesschau/news/{ressort}

News by category

news://tagesschau/regional/{region_id}

Regional news by state ID

news://tagesschau/search/{search_text}

Search results

news://tagesschau/channels

Available channels & streams

Development Guide

Setup

git clone https://github.com/Jakolo121/german-newsfeed-mcp.git
cd german-newsfeed-mcp
uv sync --extra dev

Start the server:

uv run german-newsfeed-mcp

Or:

make run

Code organisation (SOLID)

Each module has exactly one responsibility:

Module

Responsibility

config.py

Read & expose env vars

client.py

HTTP requests + error handling

rate_limiter.py

Local request budget (token bucket)

validators.py

Domain constants (VALID_RESSORTS) + input validation

formatters.py

Turn raw API dicts into Markdown

tools.py

Validate inputs, call client, call formatter

resources.py

Same as tools but for MCP resources

server.py

Composition root: assemble FastMCP, register handlers, start

Adding a new tool

  1. Add a tool_<name>() async function in tools.py

  2. Register it with @mcp.tool() in server.py

  3. Write unit + integration tests in tests/test_tools.py

Running the Tests

Unit tests (no internet required, fast)

uv run pytest -m "not integration"     # run all unit tests
uv run pytest -m "not integration" -v  # verbose output
uv run pytest tests/test_formatters.py # single file

Or:

make test

Live integration tests (requires internet)

uv run pytest -m integration           # all live tests
uv run pytest -m integration -v        # verbose

Full suite

uv run pytest

Or:

make test-all

Quality gate (lint + tests)

uv run pylint src/german_newsfeed_mcp/
uv run pytest

Or:

make check

Expected results

251 passed            ← unit tests (no network)
 22 selected          ← integration tests (live API)

Makefile Reference

make test          # fast unit tests (no network, ~0.3 s)
make test-all      # unit + live integration tests
make lint          # pylint
make check         # lint + unit tests — use as CI gate
make run           # start server in stdio mode (Claude Desktop)
make run-http      # start server in streamable-http mode
make docker-build  # build Docker image
make docker-run    # docker compose up -d
make docker-stop   # docker compose down
make docker-logs   # tail docker compose logs
make clean         # remove __pycache__, .pytest_cache, dist, etc.

Troubleshooting

Claude Desktop shows no MCP tools

  1. Check that the claude_desktop_config.json path is absolute

  2. Run uv run python main.py in the terminal, it should start without errors

  3. Fully quit and reopen Claude Desktop (Cmd+Q, not just close window)

Docker container exits immediately

docker compose logs german-newsfeed-mcp

Or:

make docker-logs

Common causes: wrong TRANSPORT value (must be streamable-http in Docker), port already in use.

API timeouts

The upstream API occasionally rate-limits certain endpoints. This is normal, the server returns a descriptive error message rather than crashing. Retry after a few seconds.

Rate-limit errors

If the server reports "Rate limit exceeded", the local request budget (RATE_LIMIT_PER_HOUR, default 60/h) is exhausted. No request was sent upstream. Try again later.

Import errors in tests

uv sync --extra dev     # ensure dev deps are installed
uv run pytest           # always run via uv, not bare pytest

When it stops working

The upstream API is not officially documented and can change without notice. You can tell by the tools suddenly returning empty lists or error messages although tagesschau.de is reachable, and by the live integration tests failing (uv run pytest tests/ -m integration).

All endpoints are defined in a single place: ENDPOINTS in src/german_newsfeed_mcp/client.py. API changes can be tracked there.

The CI job upstream-check (.github/workflows/ci.yml) runs exactly these live tests weekly against the real API and fails loudly when the response format no longer matches.

License & Acknowledgements

Apache License 2.0.

The delivered news items are content of the ARD broadcasters, subject to their rights and the terms of use of tagesschau.de, see Data Source and Terms of Use.

Thanks to AndreasFischer1985, the bund.dev community for documenting the API and above all to the journalists at the ARD broadcasters, whose work this project merely passes along.

Available Tools

5 tools
get_channelsA

Get information about available Tagesschau channels and livestreams.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It implies a read-only operation (get information) but does not disclose details such as return format, possible empty results, or whether livestream availability is dynamic. The existence of an output schema somewhat mitigates the lack of return-value details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action and resource. No redundancy or filler; every word contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool, the description is largely complete. It conveys the core purpose and distinguishes from siblings. The output schema likely covers return values. Minor gap: no mention of whether the channel list varies by region or time, which could be relevant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description need not explain parameter meanings. The schema is empty and the description accurately reflects that no input is required. This is the baseline 4 for a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the specific resource 'available Tagesschau channels and livestreams.' This distinguishes it from sibling news-content tools (get_latest_news, search_news, etc.) because it targets channel/livestream metadata rather than articles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when channel/livestream information is needed) but provides no explicit guidance about alternatives or exclusion scenarios. It does not mention sibling tools or contrast with news retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_newsA

Get the latest news from Tagesschau.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of news items to return (default: 10).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Get the latest news' with no details on sorting, time windows, or potential pagination. While not misleading, it fails to specify any behaviors beyond the basic retrieval intent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence of six words, immediately stating the core action and subject. No filler or redundancy. For a tool with one parameter, this level of brevity is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with an output schema covering return structure and a single parameter. However, the description omits any context about what constitutes 'latest', how the limit is applied, or any access constraints. Sufficient for basic use but lacking in depth for a fully informed agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single 'limit' parameter with a clear description. The tool description adds no further parameter explanation, so it does not surpass the schema's contribution. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Get') and resource ('latest news from Tagesschau'). It is unambiguous and implicitly distinguishes from sibling tools like search_news or get_news_by_ressort, which serve different needs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving current top news items, but does not explicitly state when to choose this over alternatives (e.g., search_news for queries, get_regional_news for locations). No exclusions or alternative references are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_news_by_ressortA

Get news by ressort/category.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of news items to return (default: 10).
ressortYesThe ressort/category to filter by. Options: inland, ausland, wirtschaft, sport, video, investigativ, wissen.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

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 only states the basic purpose with no disclosure of return format, pagination, error behavior, or authentication needs. The read-only nature is implied by 'Get' but not made explicit or expanded upon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the core action and resource. It is concise with no redundant words, and every part directly contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and parameters are well documented, covering return values and input details. However, the description lacks usage guidance relative to sibling tools and does not mention any behavioral constraints. For a simple get tool it is near-complete, but the missing sibling differentiation and behavioral context prevent a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% description coverage for both parameters, so the schema already explains 'ressort' and 'limit'. The description adds no additional meaning beyond restating 'ressort/category', which is already in the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with the resource 'news' and a clear filter 'by ressort/category'. It differentiates from sibling tools like get_latest_news (which suggests unfiltered latest news) and search_news (which suggests keyword-based search) by specifying a category filter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context implies using this tool when news needs to be filtered by a category, but there is no explicit when-to-use/when-not-to-use statement or mention of alternatives. The sibling names provide some clues, but the description itself offers no direct guidance on choosing this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_regional_newsA

Get regional news for a specific German state.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of news items to return (default: 10).
ressortNoOptional category filter.
region_idYesThe ID of the region/state. 1=Baden-Württemberg, 2=Bayern, 3=Berlin, 4=Brandenburg, 5=Bremen, 6=Hamburg, 7=Hessen, 8=Mecklenburg-Vorpommern, 9=Niedersachsen, 10=Nordrhein-Westfalen, 11=Rheinland-Pfalz, 12=Saarland, 13=Sachsen, 14=Sachsen-Anhalt, 15=Schleswig-Holstein, 16=Thüringen.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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 only restates the tool's purpose and does not disclose ordering, pagination, default behavior, or any constraints beyond what the schema already covers. The description adds minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that clearly states the tool's purpose. No superfluous words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool, the rich parameter schema (100% coverage), and the presence of an output schema, the description is nearly sufficient. It communicates the core purpose and geographic scope, though it misses explicit guidance on when to use it versus siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already has detailed descriptions including the region_id mapping. The description's mention of 'specific German state' reinforces region_id's purpose but adds no new semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') with a clear resource ('regional news') and scope ('specific German state'). It effectively distinguishes from siblings like get_latest_news and get_news_by_ressort by focusing on regional/state-based filtering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: 'regional news' suggests using this tool for state-specific news, while siblings cover latest, category, or search. However, no explicit guidance is given on when to prefer this over alternatives, and no exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_newsB

Search for news articles by keyword.

ParametersJSON Schema
NameRequiredDescriptionDefault
page_sizeNoResults per page (default: 10, max: 30).
result_pageNoPage number for pagination (default: 0).
search_textYesThe text to search for.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, but it only restates the search functionality. It does not disclose any behavioral traits such as result ordering, scope (global vs. filtered), or output structure (though 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every element is necessary and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description is adequate but incomplete. It does not address how it relates to sibling tools, nor does it clarify search scope or behavior beyond the literal function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage of parameter descriptions, so the tool description does not need to repeat them. The description adds no additional parameter semantics, matching the baseline of 3 for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('search') and resource ('news articles'), and the keyword mechanism distinguishes it from sibling tools that fetch by section or recency. This gives the agent a precise understanding of what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use search_news versus get_latest_news, get_news_by_ressort, etc. No alternatives or exclusions are mentioned; the usage context is left entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv2.0.2
    • First observedget_channels
    • First observedget_latest_news
    • First observedget_news_by_ressort
    • First observedget_regional_news
    • First observedsearch_news
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct retrieval mode: latest feed, category, region, keyword search, and channel info. There is no overlap in their purposes, so an agent can easily select the right tool.

Naming Consistency5/5

All tool names follow a consistent 'get_<noun>' pattern, with clear resource descriptors like 'latest_news', 'news_by_ressort', or 'channels'. This uniform naming style makes the set predictable.

Tool Count5/5

With 5 tools, the server is well-scoped for a newsfeed service. Each tool covers a necessary access pattern without redundancy, fitting comfortably within the optimal range.

Completeness5/5

The tool surface comprehensively covers the expected operations for a newsfeed: general latest news, category filtering, regional news, keyword search, and channel access. No obvious gaps exist for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • news-monitor-mcp

    malkreide
    A
    license
    A
    quality
    A
    maintenance
    MCP server for global news monitoring, media analysis and sentiment tracking via WorldNewsAPI — full-text search across 150+ countries, German/English sentiment analysis, top headlines, GL briefings, newspaper front pages and geo-search. API key required.
    15
    MIT

  • newsapi-mcp

    EventRegistry
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol (MCP) server that provides real-time news intelligence using NewsAPI.ai. This server enables LLMs to search articles, track events, and analyze news through natural conversation.
    12
    2
    MIT

  • NewsIQ MCP

    rocker2002
    F
    license
    Not graded
    quality
    D
    maintenance
    An AI-powered news aggregator MCP server that fetches live news from multiple sources, provides AI summaries via Claude, and performs sentiment analysis and trending topic detection.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jakolo121/german-newsfeed-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server