Your Product Inside Their Assistant: The SaaS Funnel Loses Its First Three Steps

A freelancer wants to know what Marc owes her this month.

First path. She searches for invoicing software, lands on a homepage, reads three bullet points, clicks "Start free trial", fills a form, verifies her address, arrives at an empty dashboard that invites her to import her clients. She closes the tab. Three days later a nudge email arrives that she never opens.

Second path. She pastes a URL into her assistant's connectors, approves one screen, asks her question, gets the amount. Forty seconds. She never saw your homepage, she does not know your name and she has used your product every day since.

For twenty years, SaaS acquisition has meant bringing someone to you. An assistant reverses the trip: your product goes to them, inside the tool they already have open. Your funnel loses its first three steps. What remains is shorter, harder to measure and harder to defend.

This article is for founders wondering whether to go, what to expect and where to start. It deliberately stays at the altitude of the decision rather than the protocol. It is the conversation I have most often right now at the start of an AI-first web product engagement, before a line is written.

What changed, in two numbers

The first number says the shelf is free. I paginated the official MCP registry API on 18 September 2026: 33,350 unique servers, 9,812 of them published in the first eighteen days of the month. Three accounts alone account for 15% of them. There is no review, no quota, no cost. The barrier to entry is zero, which moves the entire difficulty onto being chosen.

The second number says installation is gone. Here, month by month, is the share of published servers that require nothing to download, just a URL to paste:

In six months the ecosystem went from "clone this repo" to "paste this address". That is the material condition for everything else. There is nothing left to configure, so there is nothing left to justify a thirty-minute setup path, on your side or theirs.

Your funnel loses its first three steps

Put the two paths side by side, step by step.

Three rows of that table deserve a pause.

The empty state disappears. It is the number one activation killer in SaaS and it stops existing. An empty dashboard asks the user for effort before they have received anything. In a conversation the order flips: the person arrives with a question already formed, your product answers it, value comes before effort. Everything your product team built to bridge that gap, the demo data, the guided tours, the onboarding checklists, the nudge sequences, becomes moot.

Discovery is no longer yours. Your user did not compare three solutions on a feature-matrix page. Her assistant chose for her among the tools it had, reading their names and a one-line description. The positioning work does not disappear, it compresses into a single sentence read by a machine. I unpacked that selection mechanism in the article on loading tools on demand: past a few dozen available tools, clients stop showing them all to the model and hand it an index and a search instead.

The habit comes for free. SaaS retention means getting someone back into an application they tend to forget. Here, the surface is already open every morning for other reasons. You do not have to create the habit, you have to make yourself useful inside a habit that exists.

Three questions to settle before writing a line

None of these three questions is technical. All three decide the outcome.

Question 1: is your product a verb?

Chase a client, find a document, draft a quote, check stock: those gestures translate into tools an assistant can call. A dashboard, a workspace, a Kanban view: they do not. Those are surfaces. A surface is not called, it is looked at.

The test is one exercise. Name three things your product does, in three words each, with a verb first. If it comes easily, you have your first three tools. If you struggle, your value lives in the interface itself and you will ship a server nobody calls.

That question hides a deeper one, worth asking even if you never build an MCP server. A product whose value lives entirely in its interface is a product whose value lives entirely in something AI can now reproduce in a few hours.

Question 2: what goes in front of the wall?

The consent screen is the new signup form. It converts worse, because it asks for more, sooner, with scarier wording: instead of an address and a password, it announces that a piece of software is about to reach your data. It is the exact place where your activation dies.

The only counter is to put value in front of it. What, in your product, can work without an account? A calculation, a simulation, a search across your public data, an answer to a reference question. You let the first calls through, the person sees that it works, then authentication arrives when they want to act on their own data. That is a product call rather than an engineering one. It gets settled before the first line of code.

One clarification that will save you an expensive mistake: letting the first calls through does not mean going without authentication. A 2026 audit found that 25% of public MCP servers have none at all and that 53% rely on long-lived static keys. You inherit the security reputation of that category. Today it is a real acquisition cost with the teams who decide.

Question 3: who pays when a machine is calling?

Per-seat pricing rests on a simple assumption: one human, one login, one subscription. An assistant calling your tools a hundred times a day for a single person breaks the link between usage and seat count. In the other direction, one licence can now serve a whole team if the configuration travels through the organisation.

The point is not to move everything to usage-based pricing tomorrow morning. The point is to know, before opening this channel, what you are charging for: access, a volume of calls, or an outcome. Open the channel first and ask later, and you will discover your first serious users at the same time as the fact that they fit none of your plans.

Five levers that cost a week

These five levers have one thing in common: they are simple, the protocol provides for them, and almost nobody uses them. They are the ones I push hardest in scoping, because the ratio of effort to activation is the best there is.

Lever 1: ship the menu with the kitchen

The protocol lets a server provide ready-made starting points that the host displays to the user as commands to pick from. That is your getting-started guide, delivered through the channel itself, shown at the exact moment the person wonders what to do with the thing they just connected.

It is the most neglected primitive in MCP. The official tutorial lists it among the three core concepts, then builds a server that contains none. While everyone polishes their tools, the "here is what you can ask me" slot sits empty on nearly every published server.

Lever 2: ask the question at the moment of the question

The protocol also lets your server request information during execution rather than demanding it upfront. The difference in completion rate is the difference between a twelve-field form at the door and a question asked when it becomes necessary.

In practice, every field you used to collect at signup becomes a question you will only ask the people who get far enough to need it. The rest of your form you can delete.

Lever 3: let every answer carry the next step

Everything your product returns is read by the assistant and rephrased to the user. A tool response that ends with a suggested next step will be relayed, in plain language, at the moment the person has just obtained a result.

It is the cheapest onboarding email you will ever write, with a hundred percent open rate and zero delay. The guardrail: that slot has to be respected. A tool response that markets instead of helping teaches the model to prefer a competitor.

Lever 4: one user installs, the team inherits

A server's configuration lives in a file you can version alongside a project, or in an organisation's connectors. One developer adds it to the repository, every teammate who pulls the code is offered the chance to enable it. One admin enables it for the organisation, everybody has it the next morning.

It is the most effective distribution loop in this channel and it takes no extra work: your documentation simply has to show the shareable form of the configuration rather than the individual one. One buyer, N users.

Lever 5: your interface inside their conversation

Since January 2026, an official extension to the protocol, co-authored by maintainers from Anthropic and OpenAI, lets a server render its own interface directly inside the conversation. Your components, your colours, your buttons, in a sandboxed frame the host displays after the answer. The user clicks inside your product without leaving ChatGPT or Claude. The model stays aware of what they just did.

It is the most widely adopted extension of the protocol, rendered by Claude on the web and in the desktop app, by ChatGPT, by VS Code and by Cursor. It wins back what the previous four levers make you give up: your brand, your ergonomics, visual recognition. A user who sees your interface remembers your name.

What you give up

This channel has a price, and it is better to know it before you open.

The brand. Without lever 5, your product becomes a voice inside somebody else's application. The user from the opening gets her amount, she is satisfied, and she would be unable to name you. The day a competitor offers the same tool, there is no preference to overcome.

The measurement. No referrer, no tag, no journey to reconstruct. Your analytics will see nothing. If you want to know what this channel brings you, nobody will do it for you: you have to count calls per tool, identify the customers querying you and build the funnel yourself, from day one. Otherwise you will fly blind on a channel you cannot say works.

Per-seat pricing. See question 3. This channel will cost you a pricing rebuild, sooner than you expect.

Control over your visibility. Your tool is only shown to the model if it surfaces from a search you do not own, in an index you do not administer, against 33,349 other servers. You can work on your names and your descriptions, you cannot buy the top slot.

The relationship. No address captured, no welcome sequence, no direct channel. You are a tool in a catalog and the person who connected you owes you nothing.

None of these is disqualifying. Each one invalidates part of what your team knows how to do, which is reason enough to discuss them before shipping rather than after.

What I would do this week

1. Write the three verbs. Three gestures your product performs, three words each, verb first. If the exercise resists, stop there and keep the question for your next strategy review.
2. Write the line. One sentence per tool, in your users' words rather than your internal vocabulary. It is the shortest version of your positioning, and it is the one the machine that picks you will read.
3. Draw the wall. Decide what works without an account and what requires one. Write the rule down before anyone codes.
4. Ship three starting points. The three questions your best customers ask in their first week, provided as commands ready to pick.
5. Reread your tool responses. Each one should be able to end with a useful next step. Write them the way you would write a support reply, not an API payload.
6. Publish the shareable configuration. In your documentation, lead with the form that versions alongside a project.
7. Put the counter in. Calls per tool, per customer, per day, from the very first call. Without it, "is this working?" will still have no answer in six months.
8. Settle the pricing. What you charge for on this channel, decided before you have users on it.

Seven of these eight are product and marketing work. Only one needs a developer.

Closing

The channel is open, it is free and it is already crowded. What gets won there is not won with an ad budget but with three accurate verbs, a description line written to be found and a first answer that lands before the person has had to supply anything.

That is good news for teams who can articulate what their product does. It is bad news for the ones whose value mostly lived in the welcome screen.

Your user may never open your application. She can still become your best customer.