Sliq

Exa Search News

exa_search_news

A find-companies News-mode discovery source, used alongside search_news_events and tavily_search — the News-mode skill owns the routing (which signals fan out here). Each query retrieves the top recent news articles matching it, and each article comes back as pre-extracted company rows (name, domain, one-line event), so unlike tavily_search there is no article-extraction step. Covers narrative signals PredictLeads' typed categories miss (AI initiatives, role-scoped exec changes, plant incidents) and fills its zero-result gaps on typed events.

Compose queries in positive form describing the event sought, e.g. "manufacturing companies announcing new plant openings in the United States" — one query per signal, all in one call (the tool fans them out in parallel; one tool call is one LLM round). Don't embed exclusions — vector retrieval has no concept of "not", so naming an excluded term biases results towards it.

Each query retrieves the 10 most relevant recent articles. Pass lookback_days to bound how far back to look (default 30); articles published before that window are excluded server-side. A news scan passes the window from its trigger prompt.

Costs 0.5 Sliq credits per query that returns without error, so a batch of 4 queries costs 2 credits; a failed query is free. Free on BYO Exa (a connected Exa key). Soft-fails on insufficient credits: the charge is capped at the remaining balance.

When this runs in an agent, every company with a domain is saved to the Output tab as a company row (deduped by domain) carrying its article in data.signals — except a company whose domain is the article's own host, which is often the outlet's domain misread as the company's. To filter the saved companies, record a verdict on each saved row with record_search_results, under the domain it was saved with. Dict with companies array, count, and created_identifiers (the domains this call newly added to the list). Each company row is {company_name, domain, event, headquarters, source_url, title, published_at, query} — domain is lowercased-bare or None when the article didn't reveal one (resolve those downstream before recording), event is a one-line description of what happened, source_url/title/published_at identify the article, and query names the originating query. Rows are deduped by domain across queries (first article wins).

If every query failed with an upstream error and nothing landed, also exa_available: False plus a human-readable error — a source outage, NOT a genuinely empty feed. Partial failure (some queries errored, others returned) stays silent and reports only the companies.

On insufficient Sliq credits the call is refused before running — it raises InsufficientCreditsError instead.

Input Schema

TableJSON Schema

Name	Required	Description
`queries`	Yes	One positive-form news query per signal. Pass a list of one for a single-signal lookup.
`agent_id`	No	Optional — a specific agent to save the companies into. Omit it to use the running agent, which is the usual case.
`list_name`	No	Short kebab slug naming the Output-tab list bucket. Absent, companies land in the 'default' list.
`lookback_days`	No	Days of news history to scan (default 30).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 30, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional — a specific agent to save the companies into.\nOmit it 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.\nAbsent, companies land in the 'default' list."
+}

addedInput schema / properties / lookback_days / description

Added value: +"Days of news history to scan (default 30)."

First observedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Far exceeds what annotations provide: per-query cost (0.5 credits), free-on-failure, BYO-Exa exemption, credit-cap soft-fail, server-side lookback filtering, cross-query dedup by domain, automatic saving to the Output tab, the article-host exclusion quirk, and the exa_available:False error path. Annotations only set readOnlyHint=false and destructiveHint=false, so this description carries and adds substantial 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?

Front-loaded with a summary line and organized into summary/returns sections, so the reader gets purpose first. It is on the verbose side with parenthetical asides like 'one tool call is one LLM round,' but nearly every sentence carries operational information rather than filler.

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 complex multi-query discovery tool with no output schema, the description compensates thoroughly: the returns narrative documents the company row shape, dedup rules, partial-vs-total failure reporting, and the InsufficientCreditsError path. Combined with annotations and full schema coverage, an agent has everything needed to call and interpret it correctly.

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 schema already documents all four params, establishing a baseline of 3. The description adds real meaning beyond the schema: positive-form query composition, the lookback_days server-side exclusion semantics, and list_name bucketing behavior ('default' when absent), pushing it above baseline.

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?

States a specific verb and resource: 'Discover companies from recent news via Exa's semantic news search,' and frames itself as a 'find-companies News-mode discovery source.' It explicitly contrasts with siblings, noting it works alongside `search_news_events` and `tavily_search` and covers signals PredictLeads' typed categories miss, so an agent can distinguish it without opening any schema.

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?

Gives concrete guidance on composing queries (positive form, one query per signal, all in one call) and warns against embedding exclusions because vector retrieval has no concept of 'not'. It clarifies its niche versus typed-category and tavily sources. It stops short of explicit when-to-use/when-not routing, deferring that to 'the News-mode skill owns the routing,' so it is context-rich but not a full routing rule.

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

All Sliq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?