Skip to main content
Glama
mambalabsdev

Newsletter Sponsor Tracker MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Newsletter Sponsor Tracker MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs Newsletter Sponsor Tracker actor on Apify. Give it newsletter links to see who sponsors them, or a brand to see which newsletters it sponsors.

What's Inside

Related MCP server: Sponsorable MCP server

What it does

Two modes:

  • newsletter: give newsletter_urls. You get one row per sponsor found in the newest issues: sponsor name, domain, link without tracking, placements, share of issues, first and last issue seen, and issue links, plus one free summary row per newsletter.

  • brand: give brand_name and brand_domain. You get the newsletters whose recent issues carry a sponsor placement for the brand, found through Google results and confirmed in each newsletter's own issues.

Archives are read from Substack archive JSON, beehiiv and other sitemaps, or RSS. A placement is a short block with a sponsor label and the first outside link beside it.

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-newsletter-sponsor-tracker": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-newsletter-sponsor-tracker"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The track_newsletter_sponsors tool appears.

Prerequisites

Example prompts

  • "Who sponsored Not Boring and Superhuman AI in the last 20 issues?"

  • "Which newsletters has Attio sponsored recently?"

  • "List the sponsors of these five AI newsletters with how often each appeared."

Tool

track_newsletter_sponsors. One tool. Example arguments:

{
  "mode": "newsletter",
  "newsletter_urls": [
    "https://www.notboring.co"
  ],
  "issues_to_scan": "20"
}

Inputs

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

Input

Type

Description

mode

string

newsletter (default) or brand

newsletter_urls

array

Newsletter mode. Home page links or domains, up to 100

brand_name

string

Brand mode. The sponsor name

brand_domain

string

Brand mode. The sponsor domain

newsletters_to_check

string

Brand mode. 1 to 10. Default 10

issues_to_scan

string

1 to 200; at most 20 in brand mode. Default 20

since_days

string

Date window in days. Default 365

max_charge_usd

string

Optional cost cap for the run

Pricing

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

Event

Free plan

Bronze

Silver

Gold

sponsor-row, per sponsor of one newsletter

$0.004

$0.0038

$0.0036

$0.0034

brand-search, brand mode only, once per run

$0.065

$0.06175

$0.0585

$0.05525

apify-actor-start, per run start

$0.0005

$0.0005

$0.0005

$0.0005

Newsletter summary rows, no results rows, and error rows are free. The brand search event is charged when at least one candidate newsletter was read.

Your keys

The actor needs no key. It reads public newsletter archives, sitemaps, and feeds, and in brand mode Google result pages through the Apify proxy, and holds no key of any kind. Mamba Labs pays the platform and proxy costs of the run.

Full actor documentation

apify.com/mambalabs/newsletter-sponsor-tracker

License

MIT. See LICENSE.

Available Tools

1 tool
track_newsletter_sponsorsTrack newsletter sponsorsA
Read-only

Find who sponsors a newsletter, or which newsletters a brand sponsors, from public newsletter archives (Substack archive JSON, beehiiv and other sitemaps, RSS). mode newsletter: give newsletter_urls (for example notboring.co) and get one row per sponsor found in the newest issues, with sponsor name, domain, link without tracking, placements, share of issues, first and last issue seen, and issue links, plus one free summary row per newsletter. mode brand: give brand_name and brand_domain (for example Attio, attio.com) and get the newsletters whose recent issues carry a sponsor placement for the brand, found through Google results and confirmed in each newsletter's own issues. A placement is a short block with a sponsor label (presented by, brought to you by, sponsored by, together with) and the first outside link beside it. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per sponsor row and, in brand mode, one brand search event.

NameRequiredDescriptionDefault
modeNonewsletter (default): newsletter links in, sponsors out. brand: a brand in, the newsletters that ran its placements out.
brand_nameNoBrand mode. The sponsor name as newsletters print it, for example Attio.
since_daysNoStop at issues older than this many days. 0: no limit. Default 365.
brand_domainNoBrand mode. The sponsor domain, for example attio.com.
issues_to_scanNoNewest issues read per newsletter, 1 to 200; at most 20 in brand mode. Default 20.
max_charge_usdNoOptional. The run stops before any row that would take its charges over this amount.
newsletter_urlsNoNewsletter mode. Home page links or domains, up to 100, for example notboring.co.
newsletters_to_checkNoBrand mode. Candidate newsletters to confirm, 1 to 10. Default 10.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover read-only/no-destroy, but the description adds value beyond them: APIFY_TOKEN requirement, Apify's per-sponsor-row and per-brand-search-event charge model, max_charge_usd behavior, and error-with-run-ID semantics. It also discloses sourcing ('public newsletter archives ... Google results and confirmed in each newsletter's own issues'), which explains why results may be incomplete.

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 the purpose, then mode-specific usage, then mechanics/cost. Sentences are long and dense but nearly every clause is doing work; the definition of 'placement' is justified because it explains how matching is decided.

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 8 optional parameters and no output schema, the description still tells the agent what rows come back (sponsor name, domain, placements, share of issues, first/last issue, issue links, plus a free summary row), what a placement is, and what failure looks like. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does tie parameters to modes (newsletter_urls for newsletter mode, brand_name/brand_domain for brand mode) and restates the 20-issue cap in brand mode, but it adds little syntax or constraint detail the schema doesn't already carry.

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 verb and a two-sided resource ('Find who sponsors a newsletter, or which newsletters a brand sponsors') and enumerates the concrete output rows for each direction. An agent immediately knows this is sponsor/newsletter attribution mining, not generic crawling.

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?

Usage is spelled out per mode: 'mode newsletter: give newsletter_urls ... and get one row per sponsor found', 'mode brand: give brand_name and brand_domain ... and get the newsletters whose recent issues carry a sponsor placement'. There are no siblings and no exclusions to state, and the input you must supply per mode is explicit, though it doesn't state when to prefer one mode over the other beyond the obvious input shape.

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 updatev1.0.0
    • First observedtrack_newsletter_sponsors
Deploy Server
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

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation4/5

With only one tool there is no cross-tool misselection risk, but that single tool bundles two distinct operations (newsletter→sponsors and brand→newsletters) behind a 'mode' switch, so the agent must parse the description to pick the right mode and inputs.

Naming Consistency4/5

track_newsletter_sponsors is a clean snake_case verb_noun name, though 'track' is a bit loose for a read-only lookup and there is no second tool to establish a real naming pattern.

Tool Count3/5

A single tool for a narrow sponsor-tracking domain is defensible, but it is thin — the two lookup directions would be clearer as separate tools, and there is no companion tool for retrieving results of a failed run.

Completeness3/5

The core read-only lookup is covered for both directions, but the surface has dead ends: failed runs return a run ID with no tool to check status or retrieve results, and there is no way to fetch a stored/previous report.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Newsletter Commerce

    teamsincetoday
    A
    license
    Not graded
    quality
    D
    maintenance
    Extracts sponsored products, brand mentions, and affiliate signals from newsletters to generate a shoppable 'Products in this edition' section for affiliate revenue.
    3
    26 npm
    MIT

  • Sponsorable MCP server

    sponsorable
    A
    license
    Not graded
    quality
    C
    maintenance
    Connects a podcast-sponsorship database to AI assistants, allowing users to search for brands that sponsor podcasts and reveal buyer contacts by name and email.
    MIT
  • Sponsorbook MCP by Influship

    Sponsorbook MCPofficial

    Influship
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to research YouTube sponsors, inspect brands and their video evidence, explore overlapping creators and similar brands, manage research lists, and work with verified contacts.
    8 npm
    MIT