CLSTR reads 100,000+ articles a day from 40,000+ sources in 170+ countries and deduplicates them into single events, then links related events into ongoing situations with a maintained summary and a full timeline. An agent can answer what has happened over the last six weeks, not just what a single headline says right now.
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.5/5 across 4 of 4 tools scored.
The tools are clearly distinct: get_cluster retrieves a single event, get_situation_timeline retrieves a storyline's history, get_top_situations lists current situations by relevance, and search_situations finds by topic. Minor overlap exists between get_top_situations and search_situations (both return lists of situations), but their intents are separated by ranking vs. topic matching.
Three of the four tools follow a consistent verb_noun pattern (get_cluster, get_situation_timeline, get_top_situations, search_situations). The pattern is get_ for retrieval and search_ for lookup, which is predictable and readable. Minor deviation: 'get_top_situations' mixes a qualifier with noun, but it still follows the get_ prefix consistently.
With 4 tools, the server is tightly scoped for its purpose of news discovery and exploration. Each tool serves a distinct role: search, list trends, timeline, and detail, covering the core workflow without redundancy. The count is ideal for a focused news API.
The tool surface covers the primary workflows: searching topics, listing top situations, viewing a timeline, and getting event details. A minor gap is that get_cluster appears tied to a specific situation context (via 'situation it belongs to'), but it still works standalone. Pagination via cursors is mentioned for lists, but there is no explicit 'next_page' tool; however, the response includes cursors to pass back, so agents can page without a separate tool. Missing an explicit 'get_source_article' tool, but source links are provided in get_cluster.
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 details what the tool returns (summary, significance score, source count, situation, and all source articles with links) and instructs citing returned URLs. This goes beyond the readOnlyHint and openWorldHint annotations, providing concrete behavioral expectations without contradiction.
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 compact yet information-dense, starting with the primary purpose, then explaining the concept (cluster), enumerating return data, providing usage guidelines, and ending with a practical API key note. Every sentence contributes value with 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 fully explains the return payload and the tool's position in the workflow (linking to sibling tools for ID retrieval). It covers all necessary operational aspects for a single-purpose read tool without extra 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 schema already covers cluster_id with a description, and the tool description adds guidance on how to obtain valid IDs (from timelines, search, or URLs). This enriches the schema's meaning, though the core definition is already adequate, so credit for added context but not max due to redundancy.
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 'Get one news event in detail' and defines a cluster as a deduplicated real-world event, distinguishing it from near-duplicate headlines. It also references sibling tools implicitly by explaining how to obtain a cluster ID, making 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user wants the specifics of one event' and provides distinct sources for obtaining a cluster ID from sibling tools (search_situations, get_situation_timeline, or a clstr.news URL). It also notes the API key requirement, giving clear context for when and how to invoke.
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?
The annotations already declare readOnlyHint and openWorldHint, and the description adds useful context beyond that: events are deduplicated clusters, each with a significance score (with the 8+ threshold), date, source count, and canonical link. It does not describe pagination or response shape beyond the schema, but there is no contradiction and the description enriches the safety/read-only picture.
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 well structured and front-loaded: a one-line summary, then two sentences defining situation and event, then a use-case sentence, then an id-source sentence. It is four sentences with no filler; every sentence earns its place.
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?
Despite lacking an output schema, the description tells the agent what a situation timeline contains, how events are represented, when to use it, how to seed situation_id, and to cite returned URLs. Combined with the annotations and the parameter schema covering pagination behavior, this is 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three params, so the baseline is 3. The description does provide practical semantic context for situation_id by stating where to get it, but it adds little for timeline_limit and timeline_before, which are already fully described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get the full chronological timeline of one situation.' It further distinguishes itself from siblings by defining a situation as an ongoing storyline arc with maintained summary plus events in order, contrasting with get_cluster (a single event cluster) and the situation-finding 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?
The description gives explicit use cases: 'Use this to brief on a situation's history or answer "how did this develop"'. It also explains how to obtain the required situation_id via search_situations, get_top_situations, or a clstr.news URL. It doesn't explicitly mention when to use get_cluster instead, so it lacks a full when-not-to-use statement, but the guidance is clear.
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?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description enriches these with genuinely useful behavior: the intentional, non-obvious sort ('a lower significance score can rank above a higher one, and that ordering is intentional; do not re-sort'), the concept of a maintained summary with source count, and cursor-based pagination. No contradiction with annotations found.
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?
A single well-organized paragraph that front-loads the core behavior and ends with formatting guidance. Every sentence earns its place, though the enum examples for window and category do get re-stated relative to the schema, creating slight redundancy.
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?
For a tool with no output schema, the description skillfully covers the key return semantics: row identity (situation as storyline with summary and source count), the cursor for pagination, and that URLs should be cited. It is complete enough for an agent to use the tool end-to-end without needing the response format spelled out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: how the ranking should be treated on the client side, the workflow implication of the cursor ('When there are more, the result ends with a cursor to page further'), and that the sort must be preserved verbatim. This justifies a point above the baseline.
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 immediately states the verb and resource ('List the situations developing right now') and gives a precise account of the ranking blend (significance, outlet count, recency), plus a crisp definition of what a 'situation' is. It stops short of a 5 because sibling differentiation is handled through usage hints ('when there is no specific topic yet') rather than explicitly contrasting with a sibling like search_situations.
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 an explicit trigger ('what is going on in the world' / 'what is happening in <category>'), specifies when NOT to use it ('when there is no specific topic yet'), and chains the next step ('then open any result with get_situation_timeline'). It could be a 5 only if it explicitly named a search/topic sibling for the alternative case.
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 the annotations (readOnlyHint, openWorldHint), the description discloses key behavioral traits: grouping under situations, deduplication of events, result fields (summary, significance score, source count, canonical link), relevance ordering, page bounds, and cursor pagination. It also notes authentication requirement and search-cap consumption, all valuable beyond what annotations provide.
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 dense but every sentence contributes essential information: definitions, result structure, usage, follow-up tools, paging, citation, and authentication. It is longer than average but justifiably so, given the tool's complexity. It is front-loaded with the core purpose and then layers details efficiently.
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 fully explains the return format: situations with summaries, significance scores, source counts, and canonical links. It covers pagination, ordering, search-cap limits, authentication, and relationships to sibling tools. No critical behavioral or contextual information is missing for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds minimal extra parameter-specific guidance; it only reiterates the paging/search-cap behavior for cursor, which is already in the schema. Baseline of 3 is appropriate since the description doesn't add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches news by topic to find matching situations and events, and distinguishes itself by explaining the situation/cluster model. It explicitly differentiates from siblings by pointing to get_situation_timeline and get_cluster for follow-up, making the purpose and scope unambiguous.
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: 'Use this to answer 'what is happening around X' for a topic, company, country, or event.' It also gives precise alternatives: 'Then open a result with get_situation_timeline for the full history, or get_cluster for one event's detail.' Additionally, it covers paging behavior and search-cap implications, providing complete usage context.
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!
