Skip to main content
Glama
mambalabsdev

Journalist and Media List Builder MCP Server

Journalist and Media List Builder MCP Server

npm version license

An MCP server for the Mamba Labs Journalist and Media List Builder actor on Apify. Give it the beats or topics you want press for. It finds recent news articles on each one, reads the byline on each article page, and returns one row per journalist and outlet: name, outlet, author page, how many matching articles they wrote, their latest one, and the article links as proof.

What's Inside

Related MCP server: Company Discovery List Builder MCP Server

What it does

The articles come from the Mamba Labs News and Media Mention Monitor, which the actor runs on your Apify account. Press release wires are left out by default, and agency, desk, and staff bylines are never returned. When no journalist is found, one free summary row gives the article, page, and byline counts. All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-journalist-media-list-builder": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-journalist-media-list-builder"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The find_journalists tool appears.

Prerequisites

Example prompts

  • "Which journalists wrote about sales automation in the last month?"

  • "Build me a media list of reporters covering fintech funding at TechCrunch and Finextra."

  • "Find reporters who wrote at least twice about revenue operations, with their author pages."

Tool

find_journalists. One tool. Example arguments:

{
  "topics": ["\"sales automation\""],
  "since_days": "30",
  "min_articles": "1"
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and yes or no values are sent as strings.

Input

Type

Description

topics

array

1 to 20 topics or beats. Required

since_days

string

Days back, 1 to 90. Default 30

country

string

Google News country edition. Default US

language

string

Language code. Default en

outlets_include

array

Only these outlet domains

outlets_exclude

array

Never these outlet domains

include_press_releases

string

false (default) or true

min_articles

string

Least matching articles per journalist, 1 to 20. Default 1

max_articles_per_topic

string

Newest articles read per topic, 1 to 100. Default 30

max_journalists

string

Most journalist rows, 1 to 500. Default 50

max_charge_usd

string

Optional cap on the whole run, the news run included

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

journalist-row, per journalist and outlet

$0.008

$0.0076

$0.0072

$0.0068

apify-actor-start, per run start

$0.0025

$0.0025

$0.0025

$0.0025

News run article-row, per article read

$0.0023

$0.002185

$0.00207

$0.001955

News run apify-actor-start, per run

$0.0015

$0.0015

$0.0015

$0.0015

About half of news article pages name a journalist, so expect roughly 3 to 4 articles per journalist row. A summary row is free.

Your keys

The actor needs no key and holds none. Proxy traffic adds nothing to your price: Mamba Labs pays the platform costs of the run.

Full actor documentation

apify.com/mambalabs/journalist-media-list-builder

License

MIT. See LICENSE.

Available Tools

1 tool
find_journalistsFind journalists by topicA
Read-only

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.

NameRequiredDescriptionDefault
topicsYes1 to 20 topics or beats, for example "sales automation" or fintech funding.
countryNoGoogle News country edition. Default US.
languageNoLanguage code of the edition, for example en or de. Default en.
since_daysNoDays of articles to read, 1 to 90. Default 30.
min_articlesNoLeast matching articles per journalist, 1 to 20. Default 1.
max_charge_usdNoOptional cap on the whole run in USD, the news run included.
max_journalistsNoMost journalist rows, 1 to 500. Default 50.
outlets_excludeNoOutlet domains never to return.
outlets_includeNoOnly these outlet domains, for example techcrunch.com.
include_press_releasesNofalse (default) leaves out press release wires.
max_articles_per_topicNoNewest articles read per topic, 1 to 100. Default 30.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedfind_journalists

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of overlap or misselection. The tool's purpose (build a media list of journalists by topic) is clearly stated and unambiguous.

Naming Consistency4/5

find_journalists follows a clear verb_noun snake_case convention. With only one tool there is no pattern to compare against, so consistency cannot be fully demonstrated, but the name itself is predictable and descriptive.

Tool Count3/5

A single tool is thin for a server framed as a 'media list builder.' The one tool is well-scoped and parameter-rich, but the surface feels narrow and borderline minimal for the apparent domain.

Completeness3/5

The tool covers the core workflow (topics in, journalist rows with evidence out) with useful filters and clear empty/error handling. However, there are no companion operations such as saving/exporting a list, refining an existing list, or fetching a single journalist's details, leaving potential dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers