news-monitor-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.6
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.
Average 3.7/5 across 15 of 15 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![news-monitor-mcp MCP server](https://glama.ai/mcp/servers/malkreide/news-monitor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/news-monitor-mcp)

Score Badge

Copy to your README.md:

[![news-monitor-mcp MCP server](https://glama.ai/mcp/servers/malkreide/news-monitor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/news-monitor-mcp)

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