Skip to main content

Overview

The Watchlist Search MCP tool (bigdata_watchlist_search) runs one search across a saved watchlist, an inline list of Knowledge Graph entity IDs, or both. Results are grouped by entity in the order requested, so every company keeps its place even when no matching documents are found. By default, the tool returns up to five chunks per entity. This makes it useful when you want comparable coverage across a portfolio instead of allowing a few heavily covered companies to consume the whole result budget.

When to Use

Watchlist Search is ideal for:
  • Portfolio research: Run the same question across every company in a portfolio or watchlist
  • Balanced research: Reserve a result budget for each company so heavily covered names do not crowd out the rest
  • Saved-watchlist workflows: Search a watchlist by ID without copying its entities into the request
  • Cross-company screening: Apply the same date, source, document type, sentiment, or other filters to a whole list

Request

The request object is required:
Search two companies for supply-chain disruptions

Watchlists

Every item in request.watchlists must contain exactly one of:
  • id: A saved watchlist ID, which you can obtain from bigdata_get_watchlist.
  • entities: A non-empty array of Knowledge Graph entity IDs.
Each item can also set scope, which determines where its entities must occur: Lowercase scope values are normalized, but the published schema uses uppercase values. Saved and inline lists can be combined:
Duplicate entities are merged, preserving the order in which they were first requested. A missing, inaccessible, or empty saved watchlist causes the search to fail rather than silently contributing an empty list.

Chunk budgets

max_chunks controls both the result limit and how chunks are distributed: value must always be at least 1. Use a per-entity budget for even portfolio coverage. Use a shared budget when you want the strongest matches across the entire list and accept that some entities may receive no result.

Query

request.query accepts:
  • text: Optional natural-language query, 4–1,400 characters
  • filters: Optional filter object
Provide at least one effective text value or filter. A filter-only query is valid. Unknown query fields are rejected. The following bigdata_search options are not supported: search_mode, texts, reranker_text, ranking_params, external_search, response_detail, and query-level max_chunks.

Filters

Filters go inside request.query.filters and can be combined: The combined number of entity, keyword, reporting-entity, and tag filter values cannot exceed 500. Entity IDs in filters must be non-empty strings.

Response

Watchlist Search response
The response guarantees:
  • One result group per requested entity, in request order
  • An empty documents array for an entity that received no documents
  • Each chunk assigned to only one entity, even when it mentions several
  • source and timestamp may be null
  • No relevance scores or live-web documents