# AI is a serious threat to product companies. The right MCP server strategy is your defence.

> The choice is not your API versus your MCP server. Both options are MCP servers, and they look the same from outside. A standard tools/list hands your catalogue to a model and lets it own the understanding of what your users mean. A tools/ask server, which resolves intent instead, keeps that understanding and the intent to action data it produces inside your product.

By Vivek Jade · Building · published 2026-09-16 · updated 2026-09-16

Canonical page: https://thethinkingtortoise.com/article/mcp-server-moat/

## Key takeaways

- Both options are MCP servers. The choice is which one you build, not whether to build one.
- A standard tools/list over 150 APIs makes your product an execution engine behind somebody else's intelligence.
- You will not out-think a frontier model on language. But the token carries what the model never had, and a better model does not learn what you did not send.
- The meter runs on tokens, and a tools/list maximises them. Every fix on offer keeps the deciding at the model layer, which is the layer that bills.
- When your server resolves intent, models become interchangeable. Switching model vendors stops being a rewrite, because tool choice was never theirs to make.
- Tool schemas and public documentation are copyable. Millions of real requests through your own resolver are not.
- Owning intent resolution does not mean building your own model. It means owning the contract.
- Orchestration, which product takes part, can sit with the AI platform. How your product answers an authenticated user should not.

## The article

In [an earlier article](/article/mcp-tools-ask/) I argued that the industry is moving fast towards tool search, but that inside a product, search may be the wrong abstraction. The MCP server that owns the product should resolve the user's intent rather than hand a catalogue of tools to a model and ask it to choose.

That one was written for engineers, and it argued about protocol design. This one is for founders, and it is about what it costs you to get the choice wrong.

Every product company is about to ship an MCP server. There are two of them you could build, and from the outside they look the same.

**The standard one.** You take your APIs, generate tool definitions, expose `tools/list`, and let whichever model is connected work out which tool to call. This is what almost everyone is shipping.

**The one I argued for.** The request arrives in plain English. Your server combines it with everything it already knows about the product and the authenticated user, and answers.

The first is the threat. The second is the defence.

**Where will your product's intelligence live in an AI first world?**

Because if you are not careful, the answer may be: somewhere else.

## The uncomfortable future for software companies

For twenty years, software companies owned the interface. Users came to our website. They learned our navigation. They clicked our buttons. They followed workflows we designed.

AI changes that. A user may increasingly start somewhere else:

> "Move the strongest three candidates to the next stage and schedule interviews for next week."

The model now sits between the user and your product. That can be wonderful for the user. But think about what happens to the product company.

If your MCP server is a straight `tools/list` over 150 APIs, and somebody else's model decides which ones to call, your product risks becoming an execution engine behind somebody else's intelligence.

The model understands the request. The model decides what capability is required. The model chooses your API. The model handles errors. The model learns how your customers describe what they want.

And your system eventually receives something like:

```
advance_candidate_stage(candidateId, stageId)
```

You performed the transaction. But almost all of the valuable understanding happened somewhere else.

That should worry founders.

## The model knows language. You know something more valuable.

I am not suggesting that your MCP server will become smarter than frontier models. That is the wrong comparison. A frontier model understands language, reasoning and the world far better than most product specific systems ever will.

But **you understand two things better than that model can from the outside.** You understand your product. And you understand your authenticated user.

Your server knows the workflow rules. It knows the current state of the object. It knows what this tenant has configured. It knows which features are enabled. It knows the exceptions accumulated over ten years of customers asking for strange things.

And then the user token arrives. Now you also know who is asking. Their tenant. Their role. Their permissions. Their access rights. Often even the context of what they were doing moments ago.

The model sees a sentence, some tool descriptions and whatever product context somebody decided to copy into its prompt.

And this is not a gap that closes as models improve. A better model reasons better about what you send it. It does not learn what you did not send.

**Your server already holds both sides of the decision.** The product. And the user.

Why would you export all that context so that a model can reconstruct a decision you are already in a better position to make?

## A catalogue is the opposite of what an API was for

Think about the original purpose of an API. It was not supposed to expose your internal complexity. It was supposed to hide it. A caller asks for an outcome through a stable contract, and your product deals with everything underneath.

A generated `tools/list` does the opposite. It publishes every operation you have and asks the caller to work out which one is right. AI should push us further away from that, not back towards it.

So imagine that instead of exposing hundreds of operations first, your MCP server accepts:

> "Move this candidate forward."

Your server can now combine that request with the context it already owns. Perhaps the candidate is waiting for an interview. Perhaps this recruiter cannot approve an offer. Perhaps this customer's workflow requires an assessment first. Perhaps there are two valid next steps and you need to ask which one the user means.

Your server can answer:

- **Matched.** I know what capability fits.
- **Ambiguous.** I understand what you want, but I need one more piece of information.
- **Unsupported.** I understand what you want, but this product does not support it.

That is much more valuable than returning the five API descriptions whose text happens to resemble the sentence.

I called this `tools/ask` in the earlier article, because you search a catalogue but you ask a party that knows the answer. The name is not important. The ownership is.

## Why intent resolution becomes your moat

Most tool catalogues are copyable. Your competitors can see roughly what your product does. Models can learn your public documentation. Tool schemas will increasingly become standardised. A `tools/list` is unlikely to be your moat, because it is the part of your product that is easiest to reproduce.

But imagine what happens after millions of real requests pass through your own intent resolver. You begin learning:

- Which phrases mean which actions in your product.
- Which intents are regularly ambiguous.
- Which user roles commonly ask for which outcomes.
- Which product states change the correct answer.
- Which combinations of actions usually occur together.
- Where users repeatedly ask for something you do not support.
- Which workflow rules resolve requests successfully.
- Which requests require clarification, and exactly what clarification works.

This is not generic language data. It is **your proprietary intent to action data**. And it compounds.

Every successful request improves your understanding of how customers actually want to use your product. Every ambiguous request teaches your resolver another boundary. Every unsupported request tells your product team something customers want that you do not yet provide.

A `tools/list` produces none of this. The requests pass through it and the learning lands with the model provider.

The model provider learns how humans talk. **You learn what those humans mean inside your product.**

That is an asset worth owning.

## Founders should be careful about outsourcing this layer

It is tempting to think that OpenAI will solve tool search, or that Anthropic will get better at choosing my APIs. They almost certainly will. Anthropic already [searches deferred tool definitions](https://www.anthropic.com/engineering/advanced-tool-use) rather than placing every definition in model context, and [Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/tool-search) similarly lets a model describe the capability it needs and retrieves matching tools.

That is good infrastructure. Use it.

But there is a strategic difference between allowing an AI platform to help decide **which product should participate** and allowing it to become the permanent authority on **how your own product should respond to an authenticated user's intent**.

The first is orchestration. The second is product intelligence.

I would be very reluctant to outsource the second. Because once that intelligence lives outside your product, the learning lives outside your product too.

## The current design bills by the token

The economics here have teeth.

Labs bill per token, and a `tools/list` maximises tokens. Hundreds of tool definitions loaded into context. The model reasoning over them. Retries when it guesses wrong. Agentic loops burning input tokens on every turn. Labs have weak incentive to fix this properly, because the waste is revenue.

Notice that even the fixes they ship, tool search and programmatic calling, keep the intelligence at the model layer. That keeps them essential and keeps the meter running.

I cannot show that anyone intended this, and I am not claiming it. I am pointing at the shape of the incentive.

**`tools/ask` inverts that.** The product server resolves intent and the model becomes a thin conversational executor. Tokens drop by an order of magnitude.

More importantly, models become interchangeable. When the intelligence lives in the product's server, switching from Claude to Gemini to an open-weights model is trivial. Your tool choice does not change, because your tool choice was never theirs to make. Anyone who has rebuilt a prompt after a model upgrade knows what that is worth.

That is real bargaining power returning to product companies, and it commoditises exactly the layer the labs want to keep differentiated.

And it is the one advantage that does not erode. The token that arrives with the request carries this user's tenant, role, permissions, settings and what they were doing a minute ago. That is not something the model is missing by a little. It is something the model never had. So the experience stays yours to control: the user feels understood the first time, or gets a question instead of a confident wrong action, because your product decided and not something outside it.

## Building an MCP server does not mean building an LLM

This is important. Owning intent resolution does not mean every SaaS company needs an AI research team.

Your resolver could use rules, synonyms, semantic search, your existing permission engine, your workflow state, small classifiers, or a frontier model where language understanding genuinely helps. The implementation can change continuously.

What matters is that **the contract belongs to you**. The outside world says: here is what this authenticated user wants. Your product answers: here is what that means here.

That is the boundary worth protecting.

## The two MCP servers are not the same asset

Today many founders probably think of an MCP server as another integration. Something the engineering team needs to expose because ChatGPT, Claude or some agent framework wants access to the product. Generate the tool definitions, ship it, move on.

I think that undersells it badly, and it quietly picks the wrong one of the two.

Your MCP server is the place where the AI world meets your product. Not merely a wrapper around REST endpoints. Not merely a generated list of functions. A product intelligence boundary.

- It should understand intent.
- It should combine intent with authenticated context.
- It should expose what is valid now.
- It should ask when the request is unclear.
- It should refuse when the product cannot do something.

And it should learn from all five.

A catalogue does none of those, and it never will, however well it is indexed.

## The founder question

So if I were building a software company today, I would ask one question:

> When an AI agent wants something from my product, who understands what the user actually means: my product, or somebody else's model?

If the answer is always somebody else's model, I would worry. Because over time the intelligence moves outward, and your product moves downward into execution.

My recommendation to founders is simple. **Do not ship the catalogue.** Build the layer that understands your product and your authenticated user. Let people tell your product what they want in plain English. Resolve that intent yourself. Learn from every resolution.

That may become one of the few pieces of product intelligence that gets **more valuable**, rather than less valuable, as models get better.

`tools/list` tells AI what your product can do.

`tools/ask` tells AI what your product should do for this user, right now.

Both are MCP servers. Only one of them is a moat.