Skipping the API and Building the MCP Server Instead

For twenty years, if you wanted other companies to build on your software, you did one thing. You built an API. Think of an API as a door for programmers. Their code knocks, and your software answers.

A new study from InstallMap looked at 5,630 Y Combinator startups. It found something surprising. Many of the newest companies are skipping the API. Instead, they are building an MCP server. That is a different kind of door. It is built for AI assistants like Claude and ChatGPT, not for programmers.

43 of the 119 sampled YC companies with an MCP server (36.1%) show no public API we could find.

One in three. These companies built a door for AI agents and never built one for programmers. That is a real change in how software gets connected. This article explains why it is happening, what these companies gain, what they risk, and what you should ask your own team.

01 / What Is Changing

The API stopped growing. The AI doors did not.

The study checked three things on every company website.

• A public API. The classic door for programmers.
• An llms.txt file. A short page written for AI to read. It tells an AI what the company does and how to use it.
• An MCP server. A live door that lets an AI assistant take actions inside the product. Search, look things up, create things.

The researchers expected the newest startups to lead on all three. Most of them build on AI and sell to developers. So an API looked like the obvious first step. That is not what they found:

The llms.txt column does rise with every batch group. The API column does not. In the newest batches an llms.txt is more common than an API, and an MCP server is nearly as common.

Two things to keep in mind. The API and MCP numbers come from a sample of 150 companies per group. So each number could be off by about six points. Do not read too much into any one step. The gap that holds up is the big one: about 10% of companies from 2012 to 2021 run an MCP server, against 16% of companies from 2022 to 2026. Also, the study only counted what it could see on a company's own website. Some APIs were surely missed.

The real stories are in the names. Of the companies with no public API, about 6% still run an MCP server. The researchers were caught off guard:

That second group surprised us. Pave, Storylane, WayUp and Instrumentl answer on an MCP endpoint or document one, and we found no public API docs for any of them.

Look at what these companies do. Pay benchmarks. Product demos. Campus hiring. Grant search. None of them are tools for programmers. Their customers will never write code. But their customers do spend their day inside an AI assistant. So these companies built the door the customer would actually walk through.

02 / The Upside

Why skipping the API is a smart first move

Your first customer is now an AI, not a programmer. A programmer reads your manual, writes code, and ships a week later. An AI reads a one-paragraph description of your tool and uses it right away. If your buyers already work inside an AI assistant, an MCP server puts you on their menu. No code needed on either side.

An MCP server is a smaller promise. A public API is a contract. You promise it will not change. You keep old versions alive for years. You write manuals, build code libraries, and answer support tickets. An MCP server is a short list of tools with plain descriptions. Two people can build one in a week and change it the next week. For a young company that is still finding its product, a small promise is the right promise.

The description is the manual. You describe each tool once, in plain words, for the AI. That is it. No documentation website. No tutorials. The study shows how these teams think. About 71% of the MCP companies also publish an llms.txt file, against 22% of everyone else. They write for machines first.

You can offer outcomes instead of plumbing. An API usually mirrors your database. One endpoint for invoices, one for customers, one for events. An MCP tool can mirror what the user wants. "Find a time that works for these five people" instead of "list calendars, check free slots, create event." You decide how big each step is. The AI cannot wander through your system and do things you never meant it to.

It fits companies that never needed an API. The study also found no public API at Zepto, Human Interest, Stoke Space, Orange Health Labs, and Papa. The authors note that "all five sell to consumers, employers or launch customers, where an API would be unusual." For companies like these, an API was never going to happen. MCP gives them a way to plug into AI at a price they can afford.

03 / The Downside

What you quietly give up

Your caller is unpredictable. When code calls an API, it makes the same call every time. You can test it. When an AI calls an MCP tool, the same request can turn into different calls. It depends on which AI, which instructions, and which version shipped that morning. You cannot fully test a connection whose other end keeps changing its mind. We learned this building Zara, our scheduling agent. That is why we moved most of the agent into plain, predictable code. An MCP-only product pushes that unpredictability onto every customer.

You closed the door on code. MCP is built for one AI, helping one person, right now, in a conversation. Many business needs have no person in the loop. Nightly data syncs. Alerts. A partner building your product into theirs. None of those fit through an MCP door. The day a big customer asks for one, you will build the API anyway, under deadline.

You still have an API. You just never designed it. Your MCP server has to call something inside your product. That something has a shape. People will find it and depend on it. Now you have a contract with no version, no manual, and no plan for change. The study's authors say "every flag is a floor" about their own count. The same is true of your product. The API exists. It is just hidden.

Security is younger than you would like. An API key with limited permissions is boring. Boring is what you want in security. The rules for logging in to MCP servers have been rewritten more than once in a year. An AI can be tricked by text it reads from a tool. And a tool that acts with a user's full permissions is a risk by design. These problems can be solved. But today, you solve them yourself.

Billing and limits are harder. An API key is also how you charge and how you set limits. With MCP, who do you limit? The user? The AI? The company that makes the AI? When one question from a user turns into forty tool calls, who pays? The API world settled this fifteen years ago. The MCP world is settling it now.

Nobody can find you. Only 81 of the 5,630 YC companies, 1.4%, are listed in the official MCP registry. Of the 119 MCP servers in the sample, just 18 are listed. Building an MCP server does not make you findable. Someone still has to paste your address into a settings file.

The rules are still moving. MCP changed how it sends messages within its first year. The login rules were rewritten too. A plain web API from 2012 still works unchanged today. If MCP is your only public door, you are tied to a standard that is still deciding what it wants to be.

04 / How We Do It

One engine, many doors

At ANCI, the question was never "API or MCP?" The question was: what is the engine underneath, and which doors open onto it?

Zara's scheduling actions live in one engine. Find free time. Propose slots. Confirm. Reschedule. Each action has a clear input and a clear output, and it behaves the same way every time. The AI's only job is to turn a person's request into one of those actions. Nothing more.

Everything above that engine is a door. Microsoft Teams is a door. Email is a door. The web app is a door. An MCP server is a door too, and a thin one. It is a short list of tools that map straight onto actions that already exist.

The order matters. Build the engine first, and the hidden-API problem goes away, because you designed the contract before you exposed it. The unpredictable-AI problem shrinks, because every tool call lands in code that behaves the same way every time. And when a partner finally asks for a real API, you write down what already exists instead of inventing it in a hurry.

05 / What Leaders Should Do

Three questions to ask your team

Most companies do not land cleanly in either column. So ask your team three questions.

1. Where do our customers spend their day? If the answer is "inside Claude, ChatGPT, or Copilot," then an MCP server is where your product needs to show up. Soon.
2. What is our engine? Can your team list the actions your product can take, with clear inputs and outputs? If not, that list is the first thing to build. Every door depends on it.
3. Who will need the other door, and when? Name the first partner or customer who will need a real API. Plan to write it down the week they ask, not the quarter after.

The honest plan for most teams is simple. Design the engine now. Ship the MCP server this quarter, because that is where your customers are. Write down the API the first time someone outside the company needs it.

The API did not lose. The audience changed.

A public API was always a bet on who would connect to you first. For two decades, that was a programmer with code. The InstallMap numbers say the newest companies are betting on a different first visitor: an AI, acting for a customer, inside somebody else's product.

That bet can be right and still go wrong. The companies that will regret skipping the API are the ones that also skipped designing what sits under it. The companies that will be fine treated MCP for what it is. A fast, thin door for AI, built on top of an engine they took seriously. Build the engine. Then open as many doors as your customers need.