You follow a handful of companies closely. The problem isn't reading their earnings calls, it's knowing when there's something to read. A call ends at 5:30 PM, the transcript lands a few minutes later, and by the time you stumble onto it the next morning the stock has already moved and the takes are everywhere. You wanted to be early, and instead you're catching up.

What you actually want is simple: the moment a call you care about drops, get a ping, and get a short summary of what mattered. Not a dump of the full transcript, not another email digest you'll ignore, just "NVDA reported, here are the three things that moved the needle." That's a job for an earnings call alerts agent, and with MCP you can build one in an afternoon.

This is a builder how-to. It's aimed at indie hackers and automation people who are happy in a terminal and want something running today. We'll wire up a connector, teach an agent to detect new calls, have it summarize the key points, and push the result to Slack or email. Then we'll schedule it so it runs on its own.

The pieces

There are three moving parts to any AI earnings alerts setup, and none of them are heavy:

  1. A connector to the transcript corpus. This is how your agent sees earnings data. The EarningsCalls MCP server exposes the whole corpus as tools an AI can call directly: 246,000+ transcripts across 12,000+ companies, 70 countries, 170+ exchanges, all 11 GICS sectors, going back to 2020, with 11M+ speaker segments. New calls typically land within minutes of the call ending, and the corpus grows daily during earnings season. Grab a connector URL from the dashboard: go to Connectors, click Generate, and you'll get a URL shaped like https://earningscalls.dev/u/mct_xxxx/mcp.

  2. A runner: Claude Code or a scheduled agent. For interactive work, Claude Code is the fastest path. Add the connector with one command:

    claude mcp add --transport http earningscalls "https://earningscalls.dev/u/mct_xxxx/mcp"

    For the actual alerting, you'll run the same agent on a schedule (a cron job, a GitHub Action, whatever you like) so it checks for new calls without you sitting there.

  3. A notification channel. Slack and email are the obvious choices. A Slack incoming webhook is a single POST; email can go through any SMTP library or a transactional API. The agent's job ends at "here's the summary"; your channel decides where it lands.

That's the whole architecture. The corpus is the source of truth, the agent is the brain, and the channel is the doorbell.

Detecting new calls

The alerting logic has two halves: knowing when to look, and knowing whether something new has landed.

For the "when," use the upcoming-earnings tool. list_upcoming_earnings tells you which companies are scheduled to report and roughly when, so your agent knows a call is imminent and can start watching. During earnings season this is your radar: it tells you today is going to be busy and which tickers to keep an eye on.

For the "whether," you poll. After a scheduled call's expected time, the agent checks whether the transcript has actually landed. Two tools do this well:

Because transcripts land within minutes of a call ending, a poll every few minutes during the reporting window is plenty. The pattern is dead simple: remember the last call you saw for each ticker, poll, and treat any newer call as an alert trigger.

If you'd rather poll at the raw API level instead of through the agent, the REST API (base https://earningscalls.dev/api/v1, full schema at /openapi.json) supports cursor-based polling, so you page forward from your last cursor and only ever see new rows. On the Enterprise tier you can skip polling entirely and register webhooks, so new calls get pushed to you.

Building the alert agent

The flow is a straight line: on a new call, fetch it, summarize the key points, send it. The nice thing about doing this with an agent rather than hand-written code is that you describe the outcome in plain language and let the model orchestrate the tool calls.

Here's the kind of instruction you'd hand the agent:

You are an earnings-alert agent. My watchlist is: NVDA, ASML, SAP, TSM. On each run, for every ticker call get_latest_call_for_ticker. Compare the call date against the last date recorded in state.json. If a ticker has a newer call than what's recorded, it's a NEW alert: pull the transcript with get_transcript (use the summary format), then write a 4-bullet summary covering (1) revenue and EPS vs. expectations, (2) guidance changes, (3) the single most important thing from Q&A, and (4) overall management tone. Post each summary to the Slack webhook. Update state.json with the new call dates. If nothing is new, do nothing.

A few things make this work well in practice. Ask for the summary format of the transcript (get_transcript supports format="summary") rather than the full text, so you keep token usage sane and the agent stays focused. If you want to zero in on the Q&A, get_speaker_segments with a role filter pulls just the analyst and executive exchanges, which is where the real signals usually hide. And keep a tiny bit of state, a JSON file mapping ticker to last-seen call date, so the agent knows what counts as "new" and never double-alerts.

For the deeper version of this pattern, where the agent reasons across multiple calls and quarters, see Build an Earnings Research Agent with MCP and Claude. The alert agent here is the lightweight, always-on cousin of that.

Example: a watchlist alerter

Let's make it concrete. Say your watchlist is four semiconductor names and you want a Slack ping whenever any of them reports.

The run loop, once per invocation, looks like this:

  1. Read state. Load state.json, which holds the last-seen call date for each of NVDA, ASML, SAP, TSM.
  2. Probe each ticker. For each, the agent calls get_latest_call_for_ticker. This is one cheap lookup per name, not a full history scan.
  3. Diff. If the returned call is newer than what's in state, mark it as new.
  4. Fetch and summarize. For each new call, get_transcript in summary form, then the model writes the four-bullet brief.
  5. Notify. POST each brief to the Slack webhook, one message per company, with the ticker and quarter in the header so it's scannable.
  6. Persist. Write the new dates back to state.json.

On a quiet day, steps 1 through 3 run, nothing is new, and the agent exits in seconds having spent almost nothing. On a reporting day, you get a clean Slack message minutes after the call wraps. That asymmetry, cheap when idle, useful when it counts, is exactly what you want from an alerter.

The tools you'll touch for this: list_upcoming_earnings (to know when to expect a call), get_latest_call_for_ticker (the probe), get_transcript (the content), and optionally get_speaker_segments and search_transcripts for the "going further" tricks below.

Scheduling recurring runs

An alerter is only useful if it runs without you. Wrap the agent invocation in whatever scheduler you already trust:

The only real gotcha is state: your scheduled environment must persist the last-seen dates between runs, or every run will re-alert on the most recent call. A committed JSON file, a tiny KV store, or a single database row all work fine.

For a fuller treatment of running agent workflows on a schedule, including patterns for making them idempotent and cheap, see Automated Research Workflows with Claude Code and the EarningsCalls MCP.

Going further: theme-triggered alerts

A pure "new call" alert is great, but the next level is alerting only when a call contains something you actually care about. You don't want a ping for every quarter, you want a ping when management says the quiet part out loud.

This is where search_transcripts earns its keep. After a new call lands, have the agent search that transcript (or the whole recent corpus) for the phrases that matter to you, and only fire the alert if there's a hit. A few examples:

The instruction change is small: add a condition. "After fetching a new call, search it for the phrases in my watch-terms list. Only post to Slack if there's a match, and include the matching quote in the alert." Now your channel goes from noisy to signal-only.

For the broader version of this, screening the entire market for a theme rather than watching a fixed list, see Screen Earnings Calls Across the Market with MCP Tools.

Get started

Real-time earnings alerts used to mean paying for a terminal or babysitting an RSS feed. With an MCP connector and a small scheduled agent, it's a weekend project that runs itself: pinged the minute a call lands, with a summary of what mattered, and optionally only when a theme you care about shows up.

Generate a connector in the dashboard and wire it into Claude Code today. The Pro plan is $24.99/mo (5,000 calls/mo) and Ultra is $39.99/mo (25,000 calls/mo), which is plenty of headroom for a polling alerter. See the full breakdown on pricing and start getting to earnings calls before everyone else does.