Skip to main content
Glama

Search news situations

search_situations
Read-onlyIdempotent

Search 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. Pass summary: "full" to read each match's summary untruncated instead of one line. Cite the returned URLs. (Requires sign-in, or a free API key: https://clstr.news/developers)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoHow far back to search, in days. Default 7, maximum 30.
limitNoMax events to return. Default 15. They are grouped under their situations in the result, so you may see fewer situation headings than this number.
queryYesTopic, entity, company, country, or event to search for.
cursorNoFrom a previous result, to page further. Each page counts as one search against your cap.
summaryNoHow much summary text each row carries. 'preview' (the default) is a one-line preview; 'full' returns the maintained summary in full, so you do not need a follow-up call per result. On get_top_situations, 'full' is not enabled for every account: read `summary_mode` in the result to see which mode was actually served, and get_situation_timeline always returns one situation's summary in full.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
queryYesThe query as actually run: `days` is the EFFECTIVE window after tier and index clamps.
next_cursorYesPass back as cursor to page further. Each page is one search.
summary_modeYesThe summary mode this result was served in, which is not always the one requested.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / summary
      Added value: +{
      +  "description": "How much summary text each row carries. 'preview' (the default) is a one-line preview; 'full' returns the maintained summary in full, so you do not need a follow-up call per result. On get_top_situations, 'full' is not enabled for every account: read `summary_mode` in the result to see which mode was actually served, and get_situation_timeline always returns one situation's summary in full.",
      +  "enum": [
      +    "preview",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / summary_mode
      Added value: +{
      +  "description": "The summary mode this result was served in, which is not always the one requested.",
      +  "enum": [
      +    "preview",
      +    "full"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "data",
      -  "query",
      -  "next_cursor"
      -]New value: +[
      +  "data",
      +  "query",
      +  "next_cursor",
      +  "summary_mode"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "data": {
      +      "items": {
      +        "properties": {
      +          "category": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "countries": {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          },
      +          "id": {
      +            "type": "string"
      +          },
      +          "published_at": {
      +            "description": "ISO-8601 UTC timestamp.",
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "significance_score": {
      +            "description": "AI-generated significance, 1 to 10, where 8 and above is exceptional.",
      +            "type": [
      +              "integer",
      +              "null"
      +            ]
      +          },
      +          "situation": {
      +            "properties": {
      +              "cluster_count": {
      +                "minimum": 0,
      +                "type": "integer"
      +              },
      +              "id": {
      +                "type": "string"
      +              },
      +              "slug": {
      +                "type": [
      +                  "string",
      +                  "null"
      +                ]
      +              },
      +              "title": {
      +                "type": [
      +                  "string",
      +                  "null"
      +                ]
      +              }
      +            },
      +            "type": [
      +              "object",
      +              "null"
      +            ]
      +          },
      +          "slug": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "sources": {
      +            "description": "How many outlets are behind this event.",
      +            "minimum": 0,
      +            "type": "integer"
      +          },
      +          "summary": {
      +            "type": "string"
      +          },
      +          "title": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "updated_at": {
      +            "description": "ISO-8601 UTC timestamp.",
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "url": {
      +            "description": "Canonical clstr.news URL. Cite this.",
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "next_cursor": {
      +      "description": "Pass back as cursor to page further. Each page is one search.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "query": {
      +      "description": "The query as actually run: `days` is the EFFECTIVE window after tier and index clamps.",
      +      "properties": {
      +        "days": {
      +          "minimum": 1,
      +          "type": "integer"
      +        },
      +        "q": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "q",
      +        "days"
      +      ],
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "data",
      +    "query",
      +    "next_cursor"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavior on top: results are relevance ordered and bounded to top matches, each page counts as one search against the cap, and the tool requires sign-in or an API key. It also discloses pagination and summary-mode nuances ('each page counts as one search'), plus a caveat about 'full' on get_top_situations that the schema alone does not express.

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?

Although the description is long, every clause earns its place: it defines domain terms, explains result grouping, gives follow-up tool routing, discloses pagination cost, and notes auth requirements. No repeated schema details or filler are present.

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 output schema exists and the annotations declare the safety profile, the description covers everything needed to invoke the tool correctly: query intent, result shape, pagination, summary modes, auth, and follow-up tools. There is no missing call-relevant context.

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?

Schema description coverage is 100%, so the baseline is 3; the description does add value beyond the schema by clarifying that each cursor page consumes one search against the cap, and by explaining that passing summary: 'full' avoids follow-up calls per result. The query, days, and limit parameters are otherwise already well documented in the schema.

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

Purpose5/5

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

The description opens with a specific verb and resource ('Search the news by topic to find matching situations and events') and clearly distinguishes the tool's core role from its siblings by naming get_situation_timeline and get_cluster as follow-ups rather than treating this tool as the all-purpose one. It also explains the situation/event distinction, which helps an agent know what kind of result to expect.

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?

It explicitly says when to reach for this tool ('Use this to answer "what is happening around X"') and names two sibling tools as the next step for deeper exploration ('open a result with get_situation_timeline... or get_cluster for one event's detail'). The only gap is that it never contrasts search_situations with the remaining sibling get_top_situations, so differentiation is strong but not fully exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources