Skip to main content
Glama

Search news events

search_news_events

⚠️ DISCOVERY ONLY — NOT a company lookup. This returns a global feed of the most recent events matching categories + company_locations (deduped by company domain, ~10 rows). It takes NO company / domain / name input and CANNOT be scoped to a specific company or to a list of known companies. Use it ONLY for find-companies discovery ("surface net-new companies that just did X"). To research signals for a SPECIFIC named company or an uploaded prospect/account list, this is the WRONG tool — use tavily_search with a company-scoped query (e.g. " customer success news 2026") instead. search_monitor_events(company_domain=...) works too, but only for companies the user already monitors.

Use this when the user asks to DISCOVER companies by a signal that maps to one of the supported categories below. Only fall back to tavily_search if this returns no results or the signal isn't covered.

Costs 0.3 Sliq credits per event record PredictLeads returns, up to 10 records per location (so up to 3 credits per location). A location query that fails is free.

Each event's company is then checked against criteria, one company at a time, reading its name and the event, and only the events at matching companies come back in events; the rest come back in rejected as {name, reason}. It adds a few seconds per ten events.

When this runs in an agent, every event company with a domain is saved to the Output tab as a company row (deduped by domain) with its verdict, carrying the event in data.signals; the rejected ones are hidden from the list's default view.

Supported categories (pass one or more in a single call): Expansion: expands_facilities, expands_offices_in, expands_offices_to, opens_new_location, increases_headcount_by, attends_event Investment: receives_financing, goes_public, invests_into, invests_into_assets, has_earnings, has_revenue, has_valuation Leadership: hires, leaves, promotes, retires_from Contract: signs_new_client, loses_client Cost cutting: decreases_headcount_by, closes_offices_in New offering: launches, is_developing, integrates_with Partnership: partners_with, ends_partnership_with Acquisition: acquires, merges_with, sells_assets_to Challenges: declares_bankruptcy, files_suit_against, has_issues_with Recognition: receives_award, recognized_as Relational: identified_as_competitor_of, spins_off_company, spins_off_division Dict with events, the events at matching companies, each with its company's verdict ('qualified', or 'unclear' when the event says too little to judge) and verdict_reason, and a null verdict when the check couldn't run; rejected, the companies the check turned down, as {name, reason}; count, every event found, rejected ones included; and created_identifiers, the domains of matching companies this call newly added to the list. If every location-query failed with an upstream error (timeout / 5xx) and nothing landed, also predictleads_available: False plus a human-readable error — a source outage, NOT a genuinely empty feed. Partial success (some locations errored, others returned events) stays silent and reports only the events.

Input Schema

NameRequiredDescriptionDefault
agent_idNoOptional — a specific agent to save the companies into. Omit it to use the running agent, which is the usual case.
criteriaYesWhat makes a company a match for this search, in plain words: the event it must show and the kind of company (e.g. "A B2B software company that just raised a round"). Each event's company is checked against it, and the check reads nothing else of your instructions, so make it no narrower than what this call searches for. A role that is part of the signal belongs here; who you'll contact at a matching company doesn't, since the check reads that as a rule about which companies match.
list_nameNoShort kebab slug naming the Output-tab list bucket. Absent, companies land in the 'default' list. A company already on the list keeps its verdict, so to screen against new criteria, pass a new `list_name`.
categoriesYesOne or more category names from the enumerated list above (the parameter is constrained to exactly those values). Map common intents to the right name: "funding" → receives_financing, "IPO" → goes_public, "acquisition" → acquires, "layoffs" → decreases_headcount_by. Pass all relevant categories in a single call — they are fetched together at no extra cost.
on_behalf_ofNoAn agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
lookback_daysNoDays of news history to scan (default 30). A news scan passes the window from its trigger prompt.
company_locationsNoFilter by country or US state. Pass a list to cover multiple locations (e.g. ["United States", "Canada"]). At most 10 API requests are made across all locations. Omit to search globally. Prefer country-level values (e.g. "United States") over individual cities/states unless the ICP is tightly city-scoped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / list_name / description
      Previous value: -"Short kebab slug naming the Output-tab list bucket. Absent,\ncompanies land in the 'default' list."New value: +"Short kebab slug naming the Output-tab list bucket. Absent,\ncompanies land in the 'default' list. A company already on the list\nkeeps its verdict, so to screen against new criteria, pass a new\n`list_name`."
  2. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / criteria
      Added value: +{
      +  "description": "What makes a company a match for this search, in plain words:\n      the event it must show and the kind of company (e.g. \"A B2B\n      software company that just raised a round\"). Each event's\n      company is checked against it, and the check reads nothing\n      else of your instructions, so make it no narrower than what\n      this call searches for. A role that is part of the signal\n      belongs here; who you'll contact at a matching company\n      doesn't, since the check reads that as a rule about which\n      companies match.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "categories"
      -]New value: +[
      +  "categories",
      +  "criteria"
      +]
  4. Changed2 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional — a specific agent to save the companies into. Omit\nit to use the running agent, which is the usual case."
      +}
    • addedInput schema / properties / list_name
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Short kebab slug naming the Output-tab list bucket. Absent,\ncompanies land in the 'default' list."
      +}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses credit costs, per-location request limits, free failed location queries, added latency from per-company criteria checks, output-tab side effects, and how source outages appear versus genuinely empty feeds. These details materially improve invocation planning and are not contradicted by readOnlyHint=false or destructiveHint=false.

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 long, but it is front-loaded with the most important warning and discovery-only distinction. The category grouping and operational notes are structured and useful, though the full category list partially duplicates the schema enum and makes the definition longer than strictly necessary.

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 complexity, seven parameters, and absence of an output schema, the description is complete enough for correct use. It covers discovery scope, supported signals, cost, latency, side effects, returned structure, rejected records, and failure modes.

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 coverage is 100%, so the baseline is 3, but the description adds useful semantics: mapping common intents to category names, encouraging multiple categories in one call at no extra cost, explaining the criteria-check scope, and noting that `list_name` must change to re-screen against new criteria. These additions go beyond the schema descriptions, though some category information repeats the enum.

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 states a specific action and resource: discover recent news events across all companies, filtered by category and location. It explicitly distinguishes itself from a company lookup and names the scenarios it does not serve, so an agent can identify its role without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance for discovery queries and when-not-to-use guidance for specific named companies or uploaded lists. It also names concrete alternatives, `tavily_search` and `search_monitor_events(company_domain=...)`, with the conditions under which they apply.

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