News for agents: 100k+ articles/day deduplicated into situations with timelines. Free, no key.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 4 of 4 tools scored.
Each tool targets a distinct operation: single-event detail, situation timeline, current top situations, and topic search. The descriptions clearly separate the situation/event concepts, leaving no meaningful overlap or ambiguity.
All tool names follow a consistent lowercase snake_case verb_noun pattern, with get_ for retrieval and search_ for topic lookup. The names are predictable and map cleanly to their resources.
Four tools is well-scoped for a news aggregation server: one to search, one to browse current topics, one to view a situation's history, and one to inspect an individual event. Each tool earns its place and the set is easy to navigate.
The surface covers the full core workflow: discover situations via search or top list, drill into a situation timeline, and then open any individual cluster/event for detailed source information. Pagination is handled and there are no obvious missing operations for the stated purpose.
get_clusterGet a news eventAGet one news event in detail. A cluster is a single real-world event assembled from many outlets covering the same happening and deduplicated into one item, so you get one event rather than 20 near-duplicate headlines. Returns its summary, a significance score (1 to 10, where 8 and above is exceptional), a source count, the situation it belongs to if any, and every underlying source article with links. Use this when the user wants the specifics of one event. Get a cluster id from search_situations, get_situation_timeline, or a clstr.news URL. Cite the returned URLs. (Requires a free API key: https://clstr.news/developers)
| Name | Required | Description | Default |
|---|---|---|---|
| cluster_id | Yes | Cluster id or slug (from timelines, search, or clstr.news URLs). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint and openWorldHint annotations by detailing the exact output fields (summary, significance score, source count, situation, and articles) and mentioning the API key requirement, providing clear expectations of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise given the amount of information covered. It is logically structured from function to output to usage, but could be slightly streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, output, usage context, and prerequisites. It provides all necessary information for a user to decide when and how to use it, even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the cluster_id parameter clearly, and the tool description reinforces it by mentioning where to get the id. This adds helpful context but doesn't introduce entirely new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function ('Get one news event in detail') and distinguishes it from sibling tools by explaining that it retrieves a single cluster's specifics, while also providing guidance on obtaining the cluster id from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Use this when the user wants the specifics of one event') and provides instructions on how to obtain the required cluster id from search_situations, get_situation_timeline, or clstr.news URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_situation_timelineGet a situation timelineAGet the full chronological timeline of one situation. A situation is an ongoing storyline (story arc) that groups related news events over time; it carries a maintained summary plus every event in order, so you see not just what happened but how it developed. Each event is a cluster (one happening assembled from many outlets and deduplicated) with its date, a significance score (1 to 10, where 8 and above is exceptional), a source count, and a canonical clstr.news link. Use this to brief on a story's history or answer 'how did this develop'. Get a situation id from search_situations or get_top_situations, or from a clstr.news URL. Cite the returned URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| situation_id | Yes | Situation id or slug (from other tools or clstr.news URLs). | |
| timeline_limit | No | Timeline entries to return, newest first. Default 50, and 50 is also the maximum without an API key. A free key raises it to 500: https://clstr.news/developers | |
| timeline_before | No | Cursor: cluster id from a previous page to continue past. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict these. The description further discloses what the tool returns (events with date, significance score, source count, link) and the pagination mechanism, providing transparency beyond the annotations. No side effects or mutations are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, repeating definitions of 'situation' and 'event' which adds length but also clarity. It is structured logically, starting with the primary action, then explaining concepts, then use cases, then parameter sources. Could be trimmed, but every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return content (timeline events with date, significance score, source count, link), use cases, how to obtain the ID, and pagination details. Even without an output schema, the description paints a complete picture of what to expect and how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all three parameters, but the description enriches each with meaningful context: situation_id is said to come from other tools or URLs, timeline_limit has a default and maximum depending on API key access, and timeline_before is a cursor for pagination. This goes well beyond the schema's brief descriptions, fully clarifying parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the full chronological timeline of a single situation. It distinguishes itself from siblings by focusing on timeline retrieval for a specific situation, as opposed to cluster retrieval, top situations, or searching. The verb 'get' and resource 'situation timeline' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use this to brief on a story's history or answer how did this develop.' It also explains how to obtain the required situation_id from other tools or URLs, which is practical guidance. It doesn't state when not to use it, but the clarity of use cases is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_situationsTop developing situationsAList the situations developing right now, ranked by relevance: a blend of significance, how many outlets are covering it, and how recently it moved. So a lower significance score can rank above a higher one, and that ordering is intentional; do not re-sort. A situation is an ongoing storyline that groups related news events over time and carries a maintained summary and a source count (how many outlets are behind it). Optionally filter by category and by time window (24h, 7d, or 30d). Use this to answer 'what is going on in the world' or 'what is happening in ' when there is no specific topic yet, then open any result with get_situation_timeline. When there are more, the result ends with a cursor to page further. Cite the returned URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max situations to return. Default 15. | |
| cursor | No | From a previous result, to page further. Pass the same window and category alongside it. | |
| window | No | Time window. Default '7d'. | |
| category | No | Optional category filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by explaining the ranking is intentional (a lower significance score can rank above higher, so do not re-sort), describes situation definitions (ongoing storyline, summary, source count), and notes pagination via cursor. readOnlyHint and openWorldHint are consistent; 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is comprehensive but well-structured: opening states purpose and ranking, defines situations, notes filters, gives usage guidance, and mentions pagination. Each sentence adds value with no fluff; the length is justified by the need to explain non-obvious ranking behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description covers what the result contains (ranked situations with summaries and source counts, optionally a cursor). It also explains the process from query to follow-up (open with get_situation_timeline) and careful pagination. This is fully sufficient for an open-world read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant nuance: that cursor needs same window and category, and that ordering is intentional (not a parameter but influences cursor usage). It provides a couple of practical filter hints (24h,7d,30d, categories) but the schema already has enums; the unique value is the cursor interplay.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists developing situations ranked by relevance, blending significance, outlet coverage, and recency. It distinguishes itself from siblings like search_situations by specifying it handles 'what is going on' queries without a specific topic, and points to get_situation_timeline alongside.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use ('when there is no specific topic yet'), provides example queries, recommends following up with get_situation_timeline, and instructs to cite returned URLs. It also implies the alternative for specific topics (search_situations) by contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_situationsSearch news situationsASearch the news by topic to find matching situations and events. A situation is an ongoing storyline (story arc) that groups related events over time; an event, called a cluster, is one happening assembled from many outlets and deduplicated into a single item, so you get one event rather than 20 near-duplicate headlines. Results come back grouped under their situations, each with a one-line summary, a significance score (1 to 10, where 8 and above is exceptional), a source count (how many outlets are covering it), and a canonical clstr.news link. Use this to answer 'what is happening around X' for a topic, company, country, or event. Then open a result with get_situation_timeline for the full history, or get_cluster for one event's detail. Results are relevance ordered and bounded to the top matches: when there are more, the result ends with a cursor to pass back, and each page counts as one search against your cap. Cite the returned URLs. (Requires a free API key: https://clstr.news/developers)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How far back to search, in days. Default 7, maximum 30. | |
| limit | No | Max events to return. Default 15. They are grouped under their situations in the result, so you may see fewer situation headings than this number. | |
| query | Yes | Topic, entity, company, country, or event to search for. | |
| cursor | No | From a previous result, to page further. Each page counts as one search against your cap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint, the description adds substantial behavioral context: results are grouped under situations, include a significance score and source count, are relevance-ordered, and are bounded with cursor-based pagination. It also discloses API-key requirements and that each page counts against a search cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence earns its place: it defines domain-specific terms, explains result composition, gives usage guidance, and states operational constraints. It is front-loaded with the core purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains return contents, including situation summaries, significance scores, source counts, and canonical links. It also covers ordering, pagination, auth, citation expectations, and downstream workflow, making it complete for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all four parameters, so the baseline is 3. The description adds useful semantics by explaining that limit applies to events, not situation headings, and that cursor pages count as separate searches. It adds less for the days parameter, but enough to justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Search the news by topic') and resource ('matching situations and events'), then clearly defines 'situation' and 'cluster.' This distinguishes it from the sibling detail tools get_cluster and get_situation_timeline, which retrieve a single item rather than search across topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it ('Use this to answer what is happening around X') and names follow-up tools (get_situation_timeline, get_cluster). However, it does not explicitly contrast with get_top_situations or state when not to use this tool, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!