Newsletter Sponsor Tracker MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token from console.apify.com/account/integrations. The server lists its tool without a token; a call needs one. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| track_newsletter_sponsorsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
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.
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.
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.
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.