What can you do with this server?

This MCP server transforms any AI assistant into a proactive media intelligence agent, enabling global news monitoring, sentiment analysis, and trend tracking via WorldNewsAPI. Core News Retrieval * Full-text news search across 150+ countries and 50+ languages with Boolean queries, date ranges, and sorting. * Top headlines retrieval clustered by country and language, ranked by number of reporting sources. * Geo-targeted search to find location-specific news for cities/regions. * Article retrieval by ID to fetch full text and metadata. * Source search to discover news outlets by name, country, or language. * Newspaper front pages from 6,000+ publications in 125 countries. Analysis & Intelligence * Sentiment analysis for German and English content, with scores from -1 (negative) to +1 (positive), ideal for reputation monitoring. * Media briefing generation: multi-topic weekly reports with sentiment overview for up to 5 topics. * Trend radar for category-based trend detection (e.g., politics, technology) per country. Persistent Alerts * Create, list, check, and delete alerts for automatic monitoring based on sentiment thresholds, article volume, or keyword appearance. Cache Management * View cache statistics (hit rate, entries, saved API calls) and clear cache by tool type or entirely.

How do I use news-monitor-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@news-monitor-mcp Show me the top headlines from Germany today" 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.

news-monitor-mcp

by malkreide

Overview Schema Source Related Servers Score Discussions

Python

Hybrid

🇨🇭 Part of the Swiss Public Data MCP Portfolio

📰 news-monitor-mcp

Version License: MIT Python 3.11+ MCP Data Source

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.

🇩🇪 Deutsche Version

Overview

news-monitor-mcp transforms any AI assistant into a proactive media intelligence agent. The server connects LLMs like Claude with global news data: from Swiss institutional reputation monitoring to weekly leadership briefings and trend detection across categories.

Source: WorldNewsAPI (worldnewsapi.com) — the only freely available news API with German-language sentiment analysis.

API key required. Get a free key at worldnewsapi.com/console — free plan: 50 points/day, no credit card, backlink to worldnewsapi.com required (checked 2026-08-14).

Anchor demo query: "How has the Schulamt Zürich been portrayed in the media over the last 30 days, and what is the overall sentiment?"

Related MCP server: newsapi-mcp

Features

🔍 Full-text search – 150+ countries, 50+ languages, Boolean queries and exact phrase matching
📊 Sentiment analysis – German and English only (WorldNewsAPI unique feature); scores from −1 (negative) to +1 (positive)
📰 Top headlines – clustered by country and language, ranked by number of sources reporting
📋 Media briefing – multi-topic weekly report with sentiment overview for GL / leadership updates
🗞️ Newspaper front pages – digital covers from 6,000+ publications in 125 countries
📡 Trend radar – category-based trend detection (politics, technology, education, …) per country
📍 Geo-search – location-specific news (Zürich, Bern, Basel, Kanton Zürich, …)
☁️ Dual transport – stdio for Claude Desktop, Streamable HTTP for cloud deployment

#	Tool	Description
1	`news_search`	Full-text news search in 150+ countries
2	`news_top_headlines`	Top headlines by country and language
3	`news_sentiment_monitor`	Sentiment analysis for entity or topic
4	`news_media_briefing`	Multi-topic weekly briefing report
5	`news_retrieve_article`	Fetch full article by ID
6	`news_search_sources`	Find available news sources by name/country
7	`news_front_pages`	Digital newspaper front pages — paid plan required, see below
8	`news_trend_radar`	Category-based trend detection per country
9	`news_geo_search`	Location-specific news search
10	`news_alert_create`	Create a persistent alert (sentiment / volume / keyword)
11	`news_alert_list`	List configured alerts with status
12	`news_alert_check`	Evaluate alerts against current data
13	`news_alert_delete`	Permanently remove an alert
14	`news_cache_stats`	Cache hit-rate and entries by type
15	`news_cache_clear`	Clear cache (entirely or per tool type)

Demo

Media Briefing Demo

"Create a media briefing for: AI in education, Volksschule Zürich, school digitalisation"

Data Sources

Source	API Type	Content
WorldNewsAPI	REST JSON	150+ countries, 50+ languages, full text, sentiment

Prerequisites

Python 3.11+
uv or pip
API key from worldnewsapi.com/console (free tier available)

Installation

# Recommended: uvx (no install step needed)
uvx news-monitor-mcp

# Alternative: pip
pip install news-monitor-mcp

Quickstart

# Start the server (stdio mode for Claude Desktop)
WORLD_NEWS_API_KEY=your-key uvx news-monitor-mcp

Try it immediately in Claude Desktop:

"Show me the top news from Switzerland today" "How is the Schulamt Zürich covered in German-language media this month?" "Create a media briefing on: Volksschule Zürich, AI in education, school digitalisation"

Configuration

Environment Variables

Variable	Default	Description
`WORLD_NEWS_API_KEY`	–	Required. API key from worldnewsapi.com
`MCP_TRANSPORT`	`stdio`	Transport: `stdio` or `streamable_http`
`MCP_HOST`	`127.0.0.1`	HTTP bind host. Use `0.0.0.0` only inside a container.
`MCP_PORT`	`8000`	Port for HTTP transport
`MCP_BEARER_TOKEN`	–	Required in `--http` mode. Bearer token clients must present in `Authorization: Bearer <token>`. Generate via `python -c "import secrets; print(secrets.token_urlsafe(32))"`.
`MCP_ALLOWED_ORIGINS`	–	Optional CSV allowlist for the `Origin` header (DNS-rebinding protection). Example: `https://claude.ai`.
`LOG_LEVEL`	`INFO`	Log level: `DEBUG` / `INFO` / `WARNING` / `ERROR`. Logs are emitted as JSON to stderr with automatic redaction of `api-key=` query params and `Authorization: Bearer` headers.
`NEWS_MONITOR_ALERTS_DIR`	`~/.news-monitor-mcp`	Directory that holds `alerts.json`. The parent dir must not be a symlink (refused at startup as a defense against path-injection). File is created with mode `0o600`, directory with `0o700`.
`NEWS_MONITOR_ALERTS_FILE`	–	(Back-compat) explicit path to the alerts file. Same symlink check applies. Prefer `NEWS_MONITOR_ALERTS_DIR`.
`MCP_ALERT_RETENTION_DAYS`	`90`	Alerts older than this many days are deleted on server start (Privacy default per `docs/privacy-dsg.md`). Set to `0` to disable retention.
`MCP_CACHE_MAX_PER_TYPE`	`1000`	Maximum cache entries per tool type. When exceeded, the least-recently-used entry of that type is evicted. Set to `0` to disable the cap (unbounded growth — only safe for short-lived processes).
`MCP_CACHE_SWEEP_SECONDS`	`300`	Interval for the background task that removes TTL-expired entries from the cache. Set to `0` to disable the sweep (expired entries are still pruned lazily on `news_cache_stats`).

Claude Desktop Configuration

{
  "mcpServers": {
    "news-monitor": {
      "command": "uvx",
      "args": ["news-monitor-mcp"],
      "env": {
        "WORLD_NEWS_API_KEY": "your-api-key-here"
      }
    }
  }
}

Config file locations:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

After restarting Claude Desktop, all tools are available. Example queries:

"Show me the top Swiss news today"
"What is the media sentiment on AI in education this month?"
"Create a weekly briefing for: Schulamt Zürich, Volksschule, KI Bildung"
"Find all German-language articles about school digitalisation in the last 14 days"
"Show me the front pages of Swiss newspapers today"

Cloud Deployment (Streamable HTTP)

For use via claude.ai in the browser (e.g. on managed workstations without local software):

Authentication is mandatory. The HTTP transport refuses any request without a valid Authorization: Bearer <token> header. Generate a token once and keep it secret:

python -c "import secrets; print(secrets.token_urlsafe(32))"

Render.com (recommended):

Push/fork the repository to GitHub
On render.com: New Web Service → connect GitHub repo
Set the following environment variables in the Render dashboard:
- WORLD_NEWS_API_KEY — your WorldNewsAPI key
- MCP_BEARER_TOKEN — the token generated above
- MCP_HOST=0.0.0.0 — bind on all interfaces inside the container
- MCP_ALLOWED_ORIGINS=https://claude.ai (optional, recommended)
In claude.ai under Settings → MCP Servers, add the URL https://your-app.onrender.com/mcp and configure the Bearer token as the auth header.

# Local HTTP mode (binds 127.0.0.1 by default)
WORLD_NEWS_API_KEY=your-key \
  MCP_BEARER_TOKEN=$(python -c "import secrets; print(secrets.token_urlsafe(32))") \
  news-monitor-mcp --http --port 8000

# Verify auth is enforced
curl -i http://127.0.0.1:8000/mcp                                  # → 401
curl -i -H "Authorization: Bearer $MCP_BEARER_TOKEN" http://127.0.0.1:8000/mcp

Scaling notes

This server is currently single-process / single-replica:

The TTL cache lives in process memory (NewsCache). If you run multiple Render or Kubernetes replicas, each replica has its own cache — hit-rates drop linearly with the replica count.
Alerts persist to a local alerts.json (defaults to /data inside the container). Multiple replicas mounting the same persistent volume serialize via fcntl.flock, but for true cluster operation a shared store (Redis / Postgres) is needed — see the open finding SCALE-STATEFUL.
On Render Free Tier, the container sleeps after ~15 minutes of inactivity and loses non-persistent state. Attach a Persistent Disk for /data if you need alerts to survive restarts. For Render Free + alerts you must accept that the cache is lost on every wake-up.

The MCP_CACHE_MAX_PER_TYPE cap (default 1000 entries / type) and the background sweep (MCP_CACHE_SWEEP_SECONDS, default 5 min) prevent the in-process cache from growing without bound.

Container image

A non-root multi-stage Dockerfile is included and built on every CI run. Inside the container the server defaults to --http, binds 0.0.0.0:8000, persists alerts under /data, and refuses to start if MCP_BEARER_TOKEN is missing.

docker build -t news-monitor-mcp .

docker run --rm -p 8000:8000 \
  -e WORLD_NEWS_API_KEY=your-key \
  -e MCP_BEARER_TOKEN=$(python -c "import secrets; print(secrets.token_urlsafe(32))") \
  -e MCP_ALLOWED_ORIGINS=https://claude.ai \
  -v news-monitor-data:/data \
  news-monitor-mcp

Architecture

┌─────────────────┐    ┌──────────────────────────┐    ┌──────────────────────────┐
│  Claude / AI    │────▶│   News Monitor MCP        │────▶│   WorldNewsAPI           │
│  (MCP Host)     │◀────│   (MCP Server)            │◀────│   REST JSON API          │
└─────────────────┘    │                            │    │   150+ countries         │
                       │  9 Tools                   │    │   50+ languages          │
                       │  Stdio | Streamable HTTP   │    │   Sentiment DE/EN        │
                       └──────────────────────────┘    └──────────────────────────┘

Project Structure

news-monitor-mcp/
├── src/
│   └── news_monitor_mcp/
│       ├── __init__.py
│       └── server.py          # All 9 tools
├── tests/
│   ├── __init__.py
│   └── test_server.py         # 20 tests (unit + live)
├── pyproject.toml
├── CHANGELOG.md
├── CONTRIBUTING.md
├── LICENSE
├── README.md                  # This file (English)
└── README.de.md               # German version

MCP Protocol Version

This server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.

Era	Revision	Who reaches it
`initialize` handshake	`2024-11-05` … `2025-11-25`	What today's clients speak. The server answers with the revision asked for, or with the `2025-11-25` ceiling when the request asks for something newer.
Per-request envelope	`2026-07-28`	A request carrying the `2026-07-28` `_meta` envelope opens a modern connection.

Both revisions are pinned in tests/test_protocol_version.py and asserted against the installed SDK, so a Dependabot bump of mcp cannot move either one silently. The handshake ceiling is measured against a live initialize through the assembled ASGI stack, not read off a constant name.

Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern era, not for the handshake era — pinning against it alone would leave the era that current clients actually negotiate free to drift.

Update policy. When the gate fails, do not edit the constant blindly: read the spec changelog between the two revisions, verify the server still behaves, then move the constant, this section, README.de.md and CHANGELOG.md together.

Testing

# Unit + contract tests (no network) — this is what CI runs
PYTHONPATH=src pytest tests/ -m "not live"

# Live tests. The route check needs no key; the data tests skip without one.
PYTHONPATH=src pytest tests/ -m "live"

# Re-record the route inventory (writes tests/fixtures/ + PROVENANCE.md)
PYTHONPATH=src python scripts/record_fixtures.py

181 tests — 174 offline, 7 live (2 of which need no API key).

The live tests run daily at 06:17 UTC via .github/workflows/live-tests.yml, not on push: they measure the source, which changes independently of this repo.

Three live tests never ran

Until 2026-08-08 the repo's three live tests carried @pytest.mark.live but no @pytest.mark.asyncio. Under pytest-asyncio's strict default that does not mean "skipped" — it means async def functions are not natively supported. They never executed, and anyone running -m live got three errors that said nothing about the source. CI excludes -m live, so nothing reported it.

asyncio_mode = "auto" now makes a forgotten marker unable to cause this.

And running would not have shown much either:

assert "Volksschule" in result or "Ergebnisse" in result

The second branch matches the tool's own results heading, so the disjunction could not fail. assert "Top-Schlagzeilen" in result and assert "Sentiment" in result likewise matched only the template. All three now assert something that can fail, and they skip rather than fail when no key is set — "red" should mean something is wrong, not that you have no key.

What is verified without a key, and what is not

tests/fixtures/api_routen.json records, for each of the five paths the tools build, the status code and content type measured without a key. The gateway routes before authenticating:

Path	Response
the five paths the server builds	401, `application/json`
a freely invented path (control)	404, `text/html`

So a 401 means "this route exists". Without the control it would only mean "I got a 401" — and that is not a given: epl.bag.admin.ch elsewhere in this portfolio answers 401 for invented paths too. The recorder therefore re-measures the control on every run and aborts if it stops discriminating.

Still open, and marked as such in PROVENANCE.md: whether the query parameter names the server sends are correct. The API answers 401 regardless of parameters, so no key means no verification. In global-education-mcp in this same portfolio exactly that went wrong — two filters were silently inert because unknown parameters were answered with HTTP 200 and dropped. That check is outstanding, not done.

Empty result vs. changed response shape

data.get("news", []) answers two entirely different cases the same way: "the source found nothing" and "the source answers differently than we assume". The second becomes "0 results" — complete, plausible, formatted and wrong. That is not hypothetical: in global-education-mcp the envelope had been renamed, so every answer came back empty while 128 tests stayed green.

articles_of() now reads the envelope. An empty news stays an empty list — a statement by the source. A missing news is not a statement about the news but about the response, and is reported as such.

Example Use Cases

Schulamt / Institutional Communication

"How has the Schulamt Zürich been portrayed in media over the last 30 days?"
→ news_sentiment_monitor(entity="Schulamt Zürich", language="de", days_back=30)

"Create a weekly media briefing for leadership"
→ news_media_briefing(topics=["Volksschule Zürich", "KI Bildung", "Schuldigitalisierung"])

"What are Swiss media reporting on school digitalisation?"
→ news_search(query="Schuldigitalisierung", language="de", source_country="ch")

KI-Fachgruppe / AI Working Group

"What are the current tech trends in Swiss press this week?"
→ news_trend_radar(category="technology", source_country="ch", language="de")

"How are AI developments in education covered internationally?"
→ news_search(query="AI education classroom", language="en", number=20)

"Compare Swiss and German media coverage of AI regulation"
→ news_search(query="KI Regulierung", source_country="ch", language="de")
→ news_search(query="KI Regulierung", source_country="de", language="de")

City Administration / Location Research

"What is being reported about Zürich school infrastructure?"
→ news_geo_search(location="Zürich", query="Schule")

"Show today's front pages of Swiss newspapers"
→ news_front_pages(source_country="ch")

→ More use cases by audience →

Sentiment Analysis

WorldNewsAPI offers German-language sentiment analysis — rare among news APIs:

Score	Label	Meaning
> 0.3	positiv 😊	Positive coverage
−0.3 to 0.3	neutral 😐	Neutral / factual coverage
< −0.3	negativ 😟	Critical / negative coverage

⚠️ Sentiment is only available for German (de) and English (en).

Safety, Limits & Responsible Use

Read-Only Operation

12 of the 15 tools carry readOnlyHint: true. All 9 monitoring tools (search, headlines, sentiment, briefing, article, sources, front_pages, trend, geo) are fully read-only and issue GET requests to WorldNewsAPI only. The 3 exceptions are local-only operations: news_alert_create and news_alert_delete (write/ delete ~/.news-monitor-mcp/alerts.json) and news_cache_clear (clears in-memory cache). None of the 15 tools modify any external data source.

API Rate Limits

Constraint	WorldNewsAPI Free Tier	Paid Plans
Quota	50 points/day	500 – 50,000 points/day
Articles/call	Up to 100	Up to 100
Historical depth	30 days	Extended
Timeout per call	30 seconds	30 seconds

Quotas checked against worldnewsapi.com/pricing on 2026-08-14. Undated, a quota is indistinguishable from a guess after a year. Two caveats worth knowing before you plan around this table:

The API bills in points, not calls. What a request costs depends on the endpoint and its options, so there is no fixed "calls per day" figure — the earlier claim of 1,000 calls/month was both the wrong unit and the wrong magnitude.
news_front_pages does not work on the free plan. Measured 2026-08-14: /retrieve-front-page answers HTTP 403 — This endpoint is not available on the free plan. The other 14 tools were reachable on the free key.
Articles per call is not plan-dependent. Measured 2026-08-14 on the free plan: number=50 returned 50 articles, number=100 returned 100, both HTTP 200 (available: 13037 in each case). Earlier versions of this README claimed a cap of 10 for the free plan — that was this server's own default (DEFAULT_RESULTS), mistaken for a limit of the source.

The TTL cache (v0.2+) reduces redundant calls by up to 80%.

Data Privacy

No personal data stored: The server holds no persistent user data. Cache entries are in-memory and reset on server restart.
No profiling: The server retrieves publicly published journalism only. It is not designed for surveillance or personal profiling.
Alert data: Alert configurations are stored locally in ~/.news-monitor-mcp/alerts.json — on your machine only, never transmitted.

Responsible Use

Query public news only — do not use as a profiling tool for individuals.
Sentiment scores reflect algorithmic analysis of journalistic tone, not verified editorial judgements.
Results depend on WorldNewsAPI's indexing; Swiss regional media may be less well-covered than national outlets.

Terms of Service

Users must comply with:

This MCP server is an independent open-source project and is not affiliated with WorldNewsAPI.

Synergies with Other MCP Servers

news-monitor-mcp can be combined with other servers in the portfolio:

Combination	Use Case
`+ fedlex-mcp`	Law meets discourse: legal framework + media coverage
`+ global-education-mcp`	OECD stats + current media context
`+ srgssr-mcp`	Swiss public media + international news comparison
`+ swiss-environment-mcp`	Environmental data + media reporting
`+ swiss-statistics-mcp`	BFS statistics + current media narrative
`+ zurich-opendata-mcp`	City data + local media coverage

Changelog

See CHANGELOG.md

Contributing

See CONTRIBUTING.md (Deutsch).

Security & Compliance

Report vulnerabilities privately: see SECURITY.md
Swiss public-sector deployment: see docs/isds-klassifikation.md for the ISDS / Schutzbedarfsfeststellung
Swiss data protection (revDSG) — duties, profiling, retention, drittlandtransfer: docs/privacy-dsg.md
Audit history: audits/

License

MIT License — see LICENSE

Author

Hayal Oezkan · malkreide

Data: WorldNewsAPI – global news data with sentiment analysis
Protocol: Model Context Protocol – Anthropic / Linux Foundation
Related: swiss-culture-mcp – MCP server for Swiss cultural heritage data
Related: srgssr-mcp – MCP server for SRG SSR Swiss public media
Portfolio: Swiss Public Data MCP Portfolio

Installation

Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):

{
  "mcpServers": {
    "news-monitor-mcp": {
      "command": "uvx",
      "args": [
        "news-monitor-mcp"
      ]
    }
  }
}

Available Tools

15 tools

news_alert_checkA

Read-only

Prueft alle (oder einen spezifischen) Alert gegen aktuelle Nachrichtendaten.

Pro Alert 1 API-Call. Kein Cache – Alert-Checks verwenden immer aktuelle Daten. Ergebnisse (last_checked, trigger_count) werden im Alert-File persistiert.

Args: params (CheckAlertsInput): alert_id (leer = alle), response_format

Returns: str: Pruefergebnis aller Alerts mit Triggered/OK Status.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds that results (last_checked, trigger_count) are persisted in the Alert-File, which is a behavioral trait beyond the annotations. No contradictions.

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

Conciseness4/5

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

The description is concise and well-structured: a brief intro, a bullet with key behavior, and then Args/Returns sections. Every sentence adds value, though the language is German which may limit readability for some.

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 complexity (checking alerts against news data) and the presence of an output schema (not shown), the description explains the input parameters and basic behavior. However, it could elaborate on what the 'Pruefergebnis' contains beyond Triggered/OK status, and how the persistence affects subsequent operations.

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 coverage is 0% for the top-level 'params' parameter, but the nested properties 'alert_id' and 'response_format' have descriptions. The description repeats these: 'alert_id (leer = alle), response_format' and adds the return type 'str', but does not significantly add meaning beyond the schema. Baseline 3 applies.

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 'Prueft' (checks), the resource 'Alert gegen aktuelle Nachrichtendaten', and the scope 'alle (oder einen spezifischen)'. This differentiates it from sibling tools like news_alert_create or news_alert_list.

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

Usage Guidelines4/5

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

The description provides usage context: 'Pro Alert 1 API-Call. Kein Cache – Alert-Checks verwenden immer aktuelle Daten.' It implies this tool is for checking alerts with fresh data, but does not explicitly contrast with alternatives like news_alert_list or specify when to use it over other tools.

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

news_alert_createA

Erstellt einen neuen News-Alert fuer automatisches Monitoring.

Alerts werden persistent gespeichert und ueberleben Server-Neustarts. news_alert_check prueft alle Alerts gegen aktuelle Daten.

Condition-Typen: sentiment_below – Alarm wenn Ø-Sentiment < threshold (z.B. -0.2) sentiment_above – Alarm wenn Ø-Sentiment > threshold (z.B. 0.5) volume_above – Alarm wenn Artikelanzahl > threshold (z.B. 50) keyword_found – Alarm wenn keyword in Titeln/Zusammenfassungen

Args: params (CreateAlertInput): name, entity, language, source_country, days_back, condition_type, threshold, keyword

Returns: str: Bestaetigung mit der neuen Alert-ID.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior5/5

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

Description states alerts are persistent and survive server restarts, adding behavioral detail beyond annotations (which only set readOnlyHint=false, destructiveHint=false). It also explains the return format (confirmation with alert ID). No contradiction with annotations.

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

Conciseness3/5

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

Description is fairly concise, but the Args section and condition type list could be more streamlined. Some redundancy (e.g., condition types repeated). Not overly long but could be better structured.

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 presence of sibling tools and output schema (return string with alert ID), coverage is adequate but not exhaustive. Missing details on default values, error cases, or prerequisites. The life cycle (create -> check) is hinted but not fully explained.

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 0% per context, so description must compensate. It lists parameter names and explains condition types well, but omits details for parameters like language, source_country, days_back. Schema itself has descriptions for some fields, but description adds marginal value.

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 starts with 'Erstellt einen neuen News-Alert' clearly specifying creation action and resource. Sibling tools include news_alert_list, news_alert_check, news_alert_delete, so this tool is unambiguously the creation tool.

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?

Mentions that news_alert_check checks alerts against current data, implying a workflow. However, does not explicitly state when to use this tool versus alternatives (e.g., news_sentiment_monitor for continuous monitoring). Condition types are described but usage context is minimal.

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

news_alert_deleteB

DestructiveIdempotent

Loescht einen konfigurierten Alert permanent.

Args: params (DeleteAlertInput): alert_id aus news_alert_list

Returns: str: Bestaetigung oder Fehlermeldung.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations indicate destructiveHint=true and idempotentHint=true, which align with a permanent delete. However, the description fails to disclose the two-step confirm mechanism (confirm=False returns a confirmation prompt), a key behavioral trait beyond what annotations provide, leaving the agent unaware of this flow.

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

Conciseness4/5

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

The description is very short and structured with Args/Returns sections, making it easy to parse. However, it sacrifices important information about the confirm flag, which could have been included without significant bloat.

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

Completeness2/5

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

Given the tool's destructive nature and the two-step confirm pattern, the description is incomplete. It does not explain how to use confirm, the confirmation prompt, or the return format beyond 'Bestaetigung oder Fehlermeldung'. Even with an output schema present, the behavioral gap is significant for correct tool execution.

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 already describes both parameters (alert_id and confirm) with detailed descriptions. The description adds only the source of alert_id ('aus news_alert_list') but does not elaborate on the confirm parameter, providing minimal added value beyond the schema.

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

Purpose4/5

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

The description clearly states that the tool deletes a configured alert permanently, using the verb 'loescht' and specifying the resource 'Alert'. It distinguishes from siblings like news_alert_create and news_alert_list, but omits mention of the two-step confirm process.

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 advises that the alert_id comes from news_alert_list, providing minimal sourcing guidance. However, it lacks when-not-to-use instructions or alternatives, and does not mention the confirm flag's role, which is critical for proper invocation.

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

news_alert_listA

Read-onlyIdempotent

Listet alle konfigurierten News-Alerts mit Status.

Returns: str: Alle Alerts mit ID, Bedingung, letzter Pruefung und Trigger-Count. Kein API-Call – liest nur aus der lokalen Alert-Datei.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds that it reads from a local file with no API call, which is valuable behavioral context beyond annotations.

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 two sentences, concise and front-loaded. No unnecessary words. Every sentence adds value.

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

Completeness5/5

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

Given no parameters, annotations, and an output schema, the description covers purpose, behavior (local read, no API call), and return fields. Complete for the tool's complexity.

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?

No parameters exist (0 params), so schema coverage is 100%. Baseline is 4. The description does not add parameter info but explains return values adequately.

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 tool lists all configured news alerts with status, and mentions return fields. The name 'news_alert_list' and sibling tools (e.g., create, delete) make the purpose distinct.

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 does not explicitly state when to use this tool versus alternatives. However, the sibling names and the read-only nature make usage obvious. No guidance for when not to use is provided.

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

news_cache_clearA

DestructiveIdempotent

Leert den Cache (vollstaendig oder fuer einen spezifischen Tool-Typ).

Args: params (CacheClearInput): tool_type (leer = alles leeren)

Returns: str: Anzahl geloeschter Cache-Eintraege.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

The description adds value beyond annotations by explaining the confirm parameter (first call with false returns a prompt) and the return type (number of cleared entries). Annotations already indicate destructive and idempotent hints, so transparency is good.

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 extremely concise: one purpose sentence followed by clear Args and Returns sections. Every sentence adds necessary information without waste.

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 simple tool with a clear purpose and a single input object, the description covers essential aspects. It mentions the confirm parameter's behavior (though not the full details) and the return type. It does not discuss prerequisites or side effects, but the destructive hint covers that.

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

Parameters2/5

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

The description's parameter section is minimal, only mentioning tool_type with 'leer = alles leeren'. It does not mention the confirm parameter, which is crucial for safe usage. Although the input schema provides full descriptions, the tool description fails to compensate adequately, especially with 0% schema description 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 the tool clears the cache, either completely or for a specific tool type. The verb 'leert' and resource 'Cache' are specific, and the distinction between full and partial clearing distinguishes it from sibling tools like news_cache_stats.

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 clearing cache and provides the confirm parameter behavior, but does not explicitly state when to use this tool versus alternatives like news_cache_stats for monitoring. No when-not-to-use or alternative suggestions are given.

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

news_cache_statsA

Read-onlyIdempotent

Cache-Statistiken: Trefferquote, gespeicherte Eintraege, gesparte API-Calls.

Returns: str: Cache-Uebersicht mit Hit-Rate, Eintraegen nach Typ und TTL-Konfiguration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate read-only and idempotent behavior; the description adds specifics about the returned statistics (hit rate, entries by type, TTL configuration), providing additional context.

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

Conciseness4/5

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

The description is short and to the point, with the purpose stated first. Could include a brief note on when to use, but overall efficient.

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

Completeness5/5

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

For a parameterless tool with annotations covering safety and idempotency, the description fully explains what it returns and its purpose.

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?

No parameters exist, and schema coverage is 100%, so the description does not need to add parameter details.

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 it returns cache statistics (hit rate, stored entries, saved API calls), distinguishing it from sibling tools like news_cache_clear.

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?

No explicit when/when-not or alternatives provided, but the context of sibling tools and the tool's name imply it is for inspecting cache performance.

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

news_front_pagesA

Read-onlyIdempotent

Digitale Zeitungscovers von 6000+ Publikationen (Cache-TTL: 4h).

Args: params (FrontPagesInput): source_country, source_name, date, use_cache, response_format

Returns: str: Titelseiten-Uebersicht mit Bild-URLs.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate readonly and idempotent behavior. The description adds the cache TTL of 4 hours, which is valuable for understanding data freshness. No contradictions with annotations.

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

Conciseness4/5

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

The description is concise with no extraneous content, using a structured Args/Returns format. However, the Args section lacks explanations, making it less informative than it could be.

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 description covers the core function and cache behavior, but given the complexity of the input object and many sibling tools, it does not provide enough context for filtering or expected results. The presence of an output schema partially compensates, but guidance on parameters is missing.

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

Parameters2/5

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

The description merely lists parameter names (source_country, source_name, date, use_cache, response_format) without explaining their meaning, defaults, or constraints. With 0% schema description coverage, the description should compensate but does not provide enough semantic detail.

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 tool returns digitized newspaper covers from 6000+ publications, a specific resource distinct from siblings like news_top_headlines or news_retrieve_article. The verb 'returns' and resource 'Zeitungscovers' make the purpose unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions. The agent receives no context for tool selection among many news siblings.

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

news_geo_searchB

Read-onlyIdempotent

Standortspezifische Nachrichtensuche (Cache-TTL: 30 Min).

Args: params (GeoNewsInput): location, query, language, days_back, number, use_cache, response_format

Returns: str: Geolokalisierte Nachrichtenartikel mit Sentiment.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds cache TTL of 30 minutes, which is a behavioral detail not present in annotations. No contradictions.

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

Conciseness4/5

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

The description is very concise: one line for purpose and cache, then a function signature. No filler. Could be slightly more structured, but front-loads the key purpose.

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

Completeness2/5

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

Given the tool has many siblings and is location-specific, more context is needed on how the location parameter works (e.g., format, supported locations). The output schema exists but is not described. The description leaves gaps for effective use.

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

Parameters1/5

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

Schema description coverage is 0% according to context. The description lists parameter names but provides no additional meaning, constraints, or examples beyond the schema. This fails to compensate for the lack of schema descriptions.

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 it's a location-specific news search, with 'Standortspezifische Nachrichtensuche'. This distinguishes it from sibling tools like news_search and news_top_headlines by specifying the geographic scope.

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?

No explicit guidance on when to use this tool vs alternatives. The description mentions it's location-specific, but does not provide scenarios or exclusions. Sibling tools include other news search tools, but no comparative guidance.

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

news_media_briefingA

Read-only

Multi-Themen-Medien-Briefing fuer GL/KI-Fachgruppe (Cache-TTL: 60 Min pro Thema).

Args: params (MediaBriefingInput): topics (max. 5), language, days_back, source_country, use_cache

Returns: str: Kompaktes Briefing mit Sentiment und Top-3-Artikeln pro Thema.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so no contradiction. Description adds cache TTL behavior (60 min per topic) and mentions 'use_cache' parameter, which goes beyond annotations. However, no disclosure of rate limits or quota effects.

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

Conciseness4/5

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

Description is two sentences: first sentence states purpose and cache behavior, second lists arguments and return type. It is concise and front-loaded. However, it mixes German and English unnecessarily.

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 complexity of 5 parameters and output schema existence, description is partially complete. It explains caching and brief structure, but omits details like source_country format or days_back range meaning. Output schema covers return value, so minimal need for return description.

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

Parameters2/5

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

Schema has 0% description coverage, so description must compensate. It only lists parameter names (topics, language, etc.) without explaining their semantics beyond defaults. For example, 'source_country' default 'ch,de,at' is not explained. Schema itself lacks descriptions for properties.

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?

Description clearly states it provides a multi-topic media briefing for a specific group (GL/KI-Fachgruppe) with cache TTL. It distinguishes from siblings like news_search or news_alert_create by focusing on aggregated briefing. Verb 'Briefing' is specific and resource is implied.

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?

No explicit guidance on when to use this tool vs alternatives like news_search or news_alert_list. It does not state prerequisites or when not to use it. The target audience hint is present but insufficient for decision-making.

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

news_retrieve_articleA

Read-onlyIdempotent

Vollstaendigen Artikel per ID abrufen (Cache-TTL: 24h).

Args: params (RetrieveArticleInput): article_id, use_cache, response_format

Returns: str: Volltext, Metadaten und Sentiment.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context: cache TTL of 24 hours and returns 'Volltext, Metadaten und Sentiment'. No contradiction with annotations.

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 extremely concise: two sentences plus a list of args. It is front-loaded with the main purpose and cache info, with no redundant or missing elements. Every sentence adds value.

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

Completeness5/5

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

Given the tool's low complexity (few parameters, output schema present), the description is complete enough. It explains purpose, caching behavior, and return content. Annotations cover safety and idempotency, leaving no critical gaps.

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

Parameters2/5

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

With 0% schema description coverage for parameters, the description must compensate. It only lists parameter names (article_id, use_cache, response_format) without explaining their meaning, purpose, or constraints. The cache TTL mention loosely relates to use_cache but does not provide sufficient semantics.

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 'abrufen' (retrieve) and resource 'Artikel' (article) by ID. It distinguishes from sibling tools like news_search and news_top_headlines, indicating a specific retrieval action.

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 mentions cache TTL (24h) but does not explicitly state when to use this tool vs alternatives. Usage context is implied but not explicit, lacking when-not-to-use or alternative suggestions.

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

news_searchA

Read-onlyIdempotent

Volltext-Nachrichtensuche in 150+ Laendern (mit Cache, TTL: 30 Min).

Args: params (SearchNewsInput): query, language, source_country, earliest/latest_date, sort, number, include_full_text, use_cache, response_format

Returns: str: Artikel mit Titel, Zusammenfassung, Quelle, Datum und Sentiment.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context about a 30-minute cache TTL, informing the agent of caching behavior beyond the annotations.

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

Conciseness4/5

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

The description is efficient and front-loaded with the core action and caching info. However, it could benefit from structuring the parameter list more clearly, but overall it is appropriately concise.

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

Completeness2/5

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

Given the tool's complexity (15 parameters, nested input schema), the description is too brief. It lacks details on parameter formats, defaults, error behaviors, and sufficient return value information, even though an output schema exists.

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

Parameters2/5

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

The description lists parameter names (query, language, etc.) but provides no meaning or constraints beyond their names. With 0% schema coverage as per context, this is insufficient for understanding parameter semantics.

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 'Volltext-Nachrichtensuche in 150+ Laendern' (full-text news search in 150+ countries), specifying the core action and resource. This sufficiently distinguishes from sibling tools like 'news_top_headlines' or 'news_search_sources'.

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 full-text news search but offers no explicit guidance on when to use this tool versus alternatives. No exclusions or when-not-to guidelines are provided.

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

news_search_sourcesB

Read-onlyIdempotent

Verfuegbare Nachrichtenquellen suchen (Cache-TTL: 24h).

Args: params (SearchSourcesInput): name, country, language, number, use_cache, response_format

Returns: str: Liste verfuegbarer Quellen mit URL und Metadaten.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds caching behavior (Cache-TTL: 24h) and return format (list with URL and metadata), which provides useful context beyond the annotations.

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

Conciseness3/5

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

The description is very short, but it mixes German and English, which could be confusing for an agent. It front-loads the core purpose but is overly terse.

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

Completeness2/5

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

The description covers basic purpose and caching, but lacks details on parameter usage, output schema (though it mentions return type), and does not address edge cases or additional behavior. For a tool with one nested parameter and no output schema, more context is needed.

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

Parameters2/5

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

The description lists parameter names but does not explain their meaning or usage. Schema description coverage is 0%, so the description should compensate, but it only enumerates field names without clarifying e.g., how 'country' or 'language' values should be specified.

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

Purpose4/5

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

The description clearly states the purpose as searching for available news sources, with a caching detail. However, it does not explicitly differentiate from sibling tools like news_search or news_top_headlines, though the resource 'sources' is distinct.

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?

No guidance is provided on when to use this tool versus alternatives, or any prerequisites or exclusions. The description only states what the tool does.

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

news_sentiment_monitorA

Read-only

Sentiment-Analyse der Medienberichterstattung (Cache-TTL: 60 Min).

Analysiert die emotionale Tonalitaet der Berichterstattung. Nur DE und EN.

⚠️ DATENSCHUTZ-HINWEIS (revDSG, Schweiz): Sentiment-Analyse auf eine namentlich genannte Person stellt Profiling nach Art. 5 lit. f DSG dar. Vor produktivem Einsatz mit Personenbezug: Datenschutz-Folgenabschaetzung (Art. 22 DSG) und Informationspflicht (Art. 19 DSG) pruefen. Empfehlung: nur auf Institutionen / Themen, nicht auf einzelne Personen anwenden. Siehe docs/privacy-dsg.md fuer Details.

Args: params (SentimentMonitorInput): entity, language (de/en), days_back, source_country, number, use_cache, response_format

Returns: str: Sentiment-Auswertung mit Ø-Score, Statistik und Top-Artikeln.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations indicate read-only and non-destructive behavior. The description adds significant context: cache TTL (60 min), language restrictions, and a detailed privacy warning about profiling under Swiss law, which goes beyond the annotations.

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

Conciseness3/5

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

The description includes necessary sections but is somewhat verbose, especially the privacy notice. It could be more concise while retaining key 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?

Despite missing output schema details, the description covers purpose, limitations, cache behavior, privacy considerations, input arguments, and output structure. It is sufficient for a monitoring tool with moderate complexity.

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

Parameters2/5

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

Schema description coverage is 0% (only entity has a brief description). The description lists parameter names but provides no additional semantics, leaving the agent to infer meaning from names alone.

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 that the tool performs sentiment analysis of media reporting, with specific details on language support (DE and EN) and cache TTL. It is distinct from sibling tools like news_search or news_top_headlines.

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 sentiment analysis but does not explicitly compare to siblings or provide when-to-use guidelines. It mentions language limitations and a privacy warning, but lacks direct guidance on alternative tools.

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

news_top_headlinesA

Read-onlyIdempotent

Top-Schlagzeilen eines Landes (mit Cache, TTL: 15 Min).

Args: params (TopNewsInput): source_country, language, date, number, use_cache, response_format

Returns: str: Geclusterte Top-News nach Quellen-Anzahl gereiht.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds key details: caching with 15-min TTL, and that results are clustered and ranked by source count ('geclusterte Top-News nach Quellen-Anzahl gereiht'), providing significant 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.

Conciseness4/5

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

The description is concise, front-loading the purpose and including an Args list. It avoids unnecessary words, though the bilingual nature (German) might slightly reduce clarity for non-German readers.

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 that an output schema exists (though not shown), the description adequately explains return format (clustered top news ranked by source count) and caching behavior. It covers key aspects: country scope, caching, and ranking, making it sufficiently complete for the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 0%; the description only lists parameter names without explaining their meaning, constraints, or defaults. For example, 'source_country' is not defined beyond its name. The description adds minimal value over the schema for parameter understanding.

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 tool retrieves top headlines of a country ('Top-Schlagzeilen eines Landes'), with a specific verb and resource. It is distinct from sibling tools like news_search (search articles) and news_front_pages (front pages).

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 getting top news with caching (TTL 15 min), but does not explicitly state when to use this tool versus alternatives like news_search or news_trend_radar. Usage context is implied but not clearly delineated.

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

news_trend_radarA

Read-only

Nachrichtentrends in einer Kategorie (Cache-TTL: 30 Min).

Args: params (TrendRadarInput): category, source_country, language, days_back, number, use_cache, response_format

Returns: str: Trending-Themen und Artikel mit Sentiment.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds cache TTL (30 min) and return content (trending themes and articles with sentiment), providing useful behavioral context beyond annotations.

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

Conciseness4/5

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

The description is short and front-loads purpose and cache TTL. It lists parameters and return type efficiently. Slightly more parameter detail could improve it.

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 moderate complexity (7 parameters, 1 required) and presence of output schema, the description provides cache TTL and return type but lacks parameter explanations. Adequate but with clear gaps.

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

Parameters2/5

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

The description only lists parameter names without adding any meaning beyond the schema. Schema description coverage is 0%, but the description fails to compensate, offering no explanations of defaults, constraints, or examples.

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 it retrieves news trends in a category, with cache TTL. It differentiates from sibling tools like news_search and news_top_headlines by focusing on trends.

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 mentions cache TTL, implying caching behavior, but does not explicitly state when to use this tool vs alternatives like news_search or news_top_headlines. No when-not or exclusion guidance.

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.

15 tool updatesv0.3.4Jul 29, 2026
- First observednews_alert_check
- First observednews_alert_create
- First observednews_alert_delete
- First observednews_alert_list
- First observednews_cache_clear
- First observednews_cache_stats
- First observednews_front_pages
- First observednews_geo_search
- First observednews_media_briefing
- First observednews_retrieve_article
- First observednews_search
- First observednews_search_sources
- First observednews_sentiment_monitor
- First observednews_top_headlines
- First observednews_trend_radar

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct function: search, alerts, sentiment, caching, sources, front pages, trends, geo search, article retrieval, and briefings. There is minimal overlap, and descriptions clearly differentiate similar tools like news_search and news_trend_radar.

Naming Consistency5/5

All tools follow a consistent 'news_' prefix with underscore-separated verb_noun patterns (e.g., news_alert_create, news_cache_clear). The naming is uniform and predictable.

Tool Count5/5

15 tools provide a well-scoped set for news monitoring, covering search, alerts, sentiment, and media analysis without being excessive. The count is appropriate for the domain.

Completeness5/5

The tool surface is comprehensive, covering search, headlines, sentiment, alerts (CRUD), article retrieval, sources, front pages, trends, geo search, and briefings. No obvious gaps exist for the stated monitoring purpose.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Gnews A
io.github.pipeworx-io
GNews MCP — Global news search via GNews API (gnews.io)
Search Entertainment & Media
332
google-newsOAuth
io.github.johnisanerd
Google News headlines, sources, and links via the Apify Google News API, hosted MCP.
Search Web Scraping
2
Newsdata A
io.github.pipeworx-io
NewsData.io MCP — wraps the NewsData.io global news API (newsdata.io)
Search Research & Data
342
World News Feeds A
io.github.pipeworx-io
World News Feeds MCP.
Search Entertainment & Media
342

Related MCP Servers

gnews-mcp-server
Search Entertainment & Media
alejandro-ao
F
license
Not graded
quality
F
maintenance
MCP server providing access to the GNews API for fetching news articles and headlines. Supports search and top headlines with advanced filtering by language, country, category, and date.
Updated a year ago (2025-08-27 08:07 UTC)
1
-
newsapi-mcp
Search Research & Data
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.
Updated 6 months ago (2026-03-18 14:41 UTC)
12
2
MIT
News API MCP Server
Search Research & Data
berlinbra
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that provides access to global news articles through the News API. It implements a standardized interface for searching news articles, retrieving top headlines, and listing available news sources.
Updated a year ago (2025-03-29 05:27 UTC)
3
12
MIT
news-mcp-server
Search Entertainment & Media
jaij52
F
license
Not graded
quality
D
maintenance
A FastAPI MCP server that provides access to NewsAPI.org for fetching top headlines, searching articles, trending stories, and listing news sources.
Updated 5 months ago (2026-04-07 15:18 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/malkreide/news-monitor-mcp'

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

📰 news-monitor-mcp

Overview

Features

Demo

Data Sources

Prerequisites

Installation

Quickstart

Configuration

Environment Variables

Claude Desktop Configuration

Cloud Deployment (Streamable HTTP)

Scaling notes

Container image

Architecture

Project Structure

MCP Protocol Version

Testing

Three live tests never ran

What is verified without a key, and what is not

Empty result vs. changed response shape

Example Use Cases

Schulamt / Institutional Communication

KI-Fachgruppe / AI Working Group

City Administration / Location Research

Sentiment Analysis

Safety, Limits & Responsible Use

Read-Only Operation

API Rate Limits

Data Privacy

Responsible Use

Terms of Service

Synergies with Other MCP Servers

Changelog

Contributing

Security & Compliance

License

Author

Credits & Related Projects

Installation

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API