If you want programmatic access to earnings call transcripts, you now have two very different doors into the same building. You can connect an MCP server directly to an AI client like Claude, or you can call a classic REST API from your own code. Both pull from the exact same dataset. The question is not which one is "better" in the abstract, but which one fits the job in front of you.
This guide breaks down the earnings API vs MCP decision in practical terms: what each is genuinely good at, where they overlap, and how to pick based on your use case. At earningscalls.dev, both options run on one account, so you are never locked into a single path.
Quick answer
Here is the short version of the MCP vs REST API earnings decision:
- Use the MCP connector when a human or an AI agent is doing the work conversationally. If you are researching inside Claude Desktop, claude.ai, Claude Code, or Cursor and want to ask "What did NVIDIA say about data center demand last quarter?" and get an answer, MCP is the right tool. The model handles the search, retrieval, and reasoning for you.
- Use the REST API when you are writing deterministic code. If you are building an application, a dashboard, a screener, or a data pipeline that needs the same structured output every time, the REST API gives you predictable JSON, explicit parameters, and full control over pagination and error handling.
If you are still unsure after reading those two bullets, the rest of this article will make the choice obvious for your situation.
What the MCP connector is best at
The MCP connector exists to put earnings call data directly inside an AI assistant, with no glue code in between. You generate a personal connector URL in the dashboard, paste it into your client, and the model gains a set of tools it can call on your behalf.
Its strengths:
- Zero code. You do not write a single request. The AI decides which tool to call, formats the parameters, and interprets the response. Setup is copy-paste.
- Conversational research. MCP shines when questions are open-ended. "Compare how three semiconductor CEOs talked about inventory this quarter" is a natural fit. The model can chain several lookups, read transcripts, pull specific speaker segments, and synthesize an answer.
- Agent workflows. If you are building an agent or letting Claude drive a multi-step task, MCP tools are discoverable and self-describing. The agent can figure out what is available and use it without hardcoded integration.
- Fast to try. Because the token lives in the connector URL, there is no header configuration, no SDK, and no local server to run. It works across Claude Desktop, claude.ai, Claude Code, and Cursor with the same URL.
The trade-off is control. The model chooses how to query the data, so results are shaped by its reasoning rather than by a fixed contract. That is exactly what you want for exploration, and exactly what you do not want when a downstream system depends on identical output every run.
What the REST API is best at
The REST API is the tool for engineers who need determinism. It is a conventional HTTP interface at https://earningscalls.dev/api/v1, authenticated with an X-API-Key header, and documented by a full OpenAPI spec at https://earningscalls.dev/openapi.json.
Its strengths:
- Deterministic output. The same request returns the same structured JSON every time. That predictability is essential for anything that parses responses programmatically.
- Full control. You choose the endpoint, the parameters, the page size, and how you handle errors and retries. Nothing is left to a model's discretion.
- Purpose-built endpoints.
/earningsand/earnings/latestlist calls,/searchruns full-text search across the corpus, and/transcripts/{id}returns a specific transcript. For continuous ingestion, cursor-based polling lets ETL jobs pick up new calls without missing or duplicating records. - Fits any stack. Because it is plain HTTP with an OpenAPI spec, you can generate clients in any language and drop it into an existing backend, cron job, or data warehouse loader.
The trade-off is that you write and maintain the code. There is no model doing the interpretation for you, which is precisely the point when you need reliability over convenience.
A side-by-side comparison
| MCP connector | REST API | |
|---|---|---|
| Setup | Generate URL in dashboard, paste into client. No code. | Get API key, write HTTP requests against the OpenAPI spec. |
| Auth | Token embedded in the connector URL (no header). | X-API-Key request header. |
| Best for | Conversational research and AI agents. | Deterministic code, apps, and pipelines. |
| Control | Model decides how to query; less explicit control. | You control every parameter, page, and retry. |
| Works in | Claude Desktop, claude.ai, Claude Code, Cursor. | Any language or backend that speaks HTTP. |
| Latency / caching | Depends on the AI client's tool-call round trips. | Direct request/response; you own caching and cursor-based polling. |
Both routes read from the same corpus: transcripts from 2020 to present, over five years of history, 246,000+ earnings call transcripts, 12,000+ companies across 70 countries, 170+ exchanges, all 11 GICS sectors, and 11M+ speaker segments. The data does not change based on how you reach it.
Can you use both?
Yes, and most serious users do. The MCP connector and the REST API are two front doors to the same dataset, backed by the same account and the same API key. There is no separate subscription, no duplicate billing, and no divergence in coverage.
A common pattern looks like this: an analyst uses the MCP connector inside Claude for daily exploratory research, while the engineering team uses the REST API to feed a warehouse and power an internal dashboard. Both draw on the identical 246,000+ transcript corpus, and both count against the same shared rate limits and monthly quota:
- Pro — 20 requests/min, 5,000/month ($24.99)
- Ultra — 60 requests/min, 25,000/month ($39.99)
- Enterprise — 120 requests/min, 100,000/month
Because the quota is shared, you can shift usage between conversational and programmatic access freely without reprovisioning anything. If you want the deeper walkthrough of running both together, see the complete guide to earnings call transcript APIs and MCP.
Recommendation by use case
Analyst working in Claude. Use the MCP connector. Generate it from Dashboard → Connectors → Generate, paste the https://earningscalls.dev/u/mct_xxxx/mcp URL into your client, and start asking questions. You get instant access to the full transcript corpus without writing code, and the model handles search and synthesis. For step-by-step setup across clients, see add earnings call transcripts to any MCP client.
Developer building an app. Use the REST API. Structured JSON, explicit endpoints like /search and /transcripts/{id}, and the OpenAPI spec make it straightforward to integrate transcript data into a product feature, a screener, or a customer-facing dashboard. You control the response shape, so your UI never breaks on an unexpected format.
Data pipeline or ETL. Use the REST API with cursor-based polling. This is the one scenario where MCP is the wrong choice: pipelines need determinism and idempotency. Poll /earnings/latest or use the cursor to pull new calls incrementally, load them into your warehouse, and run on a schedule. Predictable input in, predictable rows out.
Mixed teams. Use both. Give analysts the MCP connector for research and give engineers the REST API for automation. Same account, same key, same data, one bill.
Bottom line
The earnings API vs MCP question is really a question about who is doing the work. If it is a person or an AI agent exploring conversationally, reach for the MCP connector. If it is code that needs the same answer every time, reach for the REST API. And since both run on a single account with a shared quota, you do not have to choose forever, you can start with one and add the other whenever your needs change.
Ready to connect your earnings call data? Pick a plan on the pricing page and generate your connector or API key from the dashboard in minutes.