Journalist and Media List Builder MCP Server

Find journalists by topic

find_journalists

Read-only

Build a media list of journalists who recently covered specified topics or beats by reading article bylines and returning names, outlets, author pages, article counts, and evidence links.

Instructions

Build a media list of journalists who recently wrote about given topics or beats. Give topics (1 to 20; quotes for an exact phrase) and optionally since_days, country, outlets_include, outlets_exclude, min_articles, and max_journalists. The actor reads recent Google News articles through the Mamba Labs News and Media Mention Monitor, reads each article page's byline, and returns one row per journalist and outlet: journalist_name, outlet, outlet_domain, author_page_url, x_handle, article_count, latest_article_title, latest_article_url, latest_published_at, topics_matched, and article_urls as evidence. Press release wires and desk or agency bylines are left out. No emails are returned. When none is found, one free summary row says why. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per journalist returned plus the news run's price per article read.

Input Schema

Name	Required	Description
`topics`	Yes	1 to 20 topics or beats, for example "sales automation" or fintech funding.
`country`	No	Google News country edition. Default US.
`language`	No	Language code of the edition, for example en or de. Default en.
`since_days`	No	Days of articles to read, 1 to 90. Default 30.
`min_articles`	No	Least matching articles per journalist, 1 to 20. Default 1.
`max_charge_usd`	No	Optional cap on the whole run in USD, the news run included.
`max_journalists`	No	Most journalist rows, 1 to 500. Default 50.
`outlets_exclude`	No	Outlet domains never to return.
`outlets_include`	No	Only these outlet domains, for example techcrunch.com.
`include_press_releases`	No	false (default) leaves out press release wires.
`max_articles_per_topic`	No	Newest articles read per topic, 1 to 100. Default 30.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover safety (readOnlyHint, destructiveHint=false), but the description adds substantial context beyond them: press release wires and desk/agency bylines are excluded, no emails are returned, empty results yield one free summary row explaining why, failures return an error with a run ID, and it requires an APIFY_TOKEN with per-journalist plus per-article pricing. This is exactly the operational detail an agent needs before committing to a paid run.

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 purpose, then inputs, then return columns, then exclusions/cost. Each sentence carries information. It is dense but not padded; the returned-field enumeration is the longest stretch but is justified because no output schema exists.

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?

With 11 parameters and no output schema, the description carries the full burden, and it does: it enumerates every returned column, documents the degenerate (no results) and error cases, and discloses auth and billing. Nothing an agent needs to call this correctly is missing.

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. The description adds value beyond the schema by noting the topic count range and that quotes force an exact-phrase match, and by naming the optional filter parameters as a coherent set. It doesn't explain the semantics of max_charge_usd or include_press_releases beyond what the schema states.

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?

Opens with a specific verb+resource: 'Build a media list of journalists who recently wrote about given topics or beats.' It states the data source (Google News via Mamba Labs News and Media Mention Monitor) and the extraction method (article page byline), leaving no ambiguity about what the tool produces.

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 gives clear input context ('give topics... and optionally since_days, country...') and implies the outreach/media-list use case. There are no sibling tools to route against and no explicit when-not-to-use guidance, so it stops short of a 5.

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

Deploy Server

Other Tools

find_journalistsA