I Think MCP Will Punish Thin API Wrappers

Right, and the uncomfortable part is that this was already true before MCP — it just wasn’t enforced. You could ship a thin wrapper, slap a UI on top, and the friction of “users don’t want to read API docs” was enough to keep you in business. That friction was doing a lot of load-bearing work that founders mistook for product value.
MCP removes that friction almost entirely. The agent reads docs faster than any user, doesn’t get tired of authentication flows, and has no loyalty to your UI. So the wrapper layer that used to be defensible by inconvenience suddenly isn’t. Whatever was real underneath — workflow, opinionated defaults, accumulated state, trust — is what’s left standing. Whatever wasn’t, evaporates.
The honest version of your line is: MCP isn’t killing thin wrappers, it’s just turning off the life support they didn’t realize they were on.

The REST analogy is the right one and I think it predicts the shape of the next two years pretty cleanly. The first wave of MCP servers will look a lot like the first wave of REST wrappers — lots of them, mostly thin, and the survivors will be the ones that did something the underlying API couldn’t do on its own.
For FORMLOVA, the differentiator isn’t “we let agents create forms.” That’s the thin-wrapper version, and if that were the whole pitch I’d already be in trouble. The real surface is what happens around the form, not the form itself. A few things compound:
The product is MCP-native, not MCP-bolted-on. There’s no dashboard you have to leave the chat to use. Every operation — creating a form, publishing, configuring auto-replies, integrating with Sheets, analyzing responses, building reports — happens through tools the agent calls directly. That sounds cosmetic but it changes the shape of the surface. The tools are designed around what an operator actually wants to do, not around what the database tables look like. So the agent doesn’t have to assemble five primitives to accomplish one obvious task.
The semantics of the response layer are part of the product. Form submissions get classified, deduplicated, filtered, and locked when a human corrects them. Those aren’t features you turn on; they’re the default state the agent sees. So an agent reasoning about “did this lead reply” or “show me legitimate signups this week” doesn’t have to rebuild that logic in a prompt every time. The product already knows.
The integrations are workflow-shaped, not endpoint-shaped. set_workflow, auto-reply configuration, Sheets sync, duplicate prevention — these are intent-level operations the agent can compose without understanding the underlying plumbing. That’s the layer competitors will struggle to copy quickly, because it requires opinions about how form-driven workflows actually run, not just API coverage.
So the moat, to use your word, isn’t the MCP server. It’s the accumulated product judgment that the MCP server makes legible to the agent. A thin wrapper around Typeform’s API would expose 30 endpoints and call it a day. FORMLOVA exposes around 115 tools, but each one is a verb an operator would actually say out loud.
Happy to have you dig in. The site is formlova.com, and the MCP server is live if you want to connect it to a client and see how the surface feels from the agent’s side rather than from a screenshot. That’s usually where the difference becomes obvious.

The “blast radius” framing is the part I want to steal. That’s the cleanest articulation I’ve seen of why a primitive-only API surface fails the agent, even when the data is technically all there.
A primitive surface forces the agent to reconstruct relationships every call. Which Figma frame relates to this feature? Which endpoints does it touch? Which code paths break if it changes? The information exists somewhere in the system, but it’s scattered across tables and the agent has to traverse it from scratch each time. That traversal is where errors enter — not because the model is bad at reasoning, but because the inputs are too low-level for the reasoning to be reliable. Five steps of derivation is five places to be subtly wrong.
A spec layer that already encodes those connections collapses the derivation. The agent doesn’t ask “what does this feature touch” — it reads the answer. And critically, the answer carries the system’s authoritative view, not the agent’s reconstructed guess. That’s the difference between an integration that gets sharper as the product matures and one that stays brittle no matter how good the model gets.
The connection to the thin wrapper problem is exactly what you said, and I’d put it this way: a thin wrapper assumes the primitives are the meaning. A spec-aware product knows the meaning lives in the relationships between primitives, and the integration’s job is to expose those relationships, not just the primitives. Stripping that out at the boundary is how you turn a sophisticated product into a generic CRUD surface from the agent’s point of view, regardless of how rich the underlying system actually is.
What you’re building sounds like the same insight applied to software development itself, which is interesting because development is the domain where the cost of an agent re-deriving blast radius is highest. A wrong autoreply on a form is annoying. A wrong assumption about what a code change touches is a production incident. So the meaning-preservation pressure is even higher there. Curious what you’re calling it and where you are with it.

Exactly. API design optimizes for system completeness; intent design optimizes for the user’s actual job. With MCP, the LLM is the user — and it doesn’t want 12 atomic calls to accomplish one obvious task. It wants the task.
This is why I think a lot of “MCP servers” shipped today are going to age badly. They’re just OpenAPI specs in a new wrapper. The winners will be the ones that rebuild the surface around verbs the model would actually reach for.

Great example — recent_intentional_captures vs list_entries+filters is exactly the shift. The classification belongs server-side because the meaning lives there.
On naming and descriptions, my working rules:
Tool names should read like things the user would say out loud, not like functions. publish_form, not forms.update(status=“published”). The verb carries the intent; the name shouldn’t require the agent to infer side effects.
Descriptions should answer “when would I reach for this?” before “what does it do?” The agent’s selection problem is closer to retrieval than to reading docs. I write the first sentence as if it were a search snippet — what situation triggers this tool. The parameter docs come after.
Keep the surface small. Every additional tool dilutes selection accuracy. I’d rather have 20 sharp intent tools than 80 thorough ones. If two tools overlap in description space, the agent will pick wrong roughly half the time.
On the escape hatch — yes, but I gate it. I expose a small set of lower-level tools (raw query, raw update) but mark them clearly as “use only when no intent tool fits.” In practice the model respects that prefix surprisingly well. The bigger risk isn’t the agent misusing the escape hatch; it’s the agent defaulting to it because the high-level tools are vague. If you find the model reaching for the low-level tools often, that’s a signal your intent layer has a gap, not that the escape hatch is wrong.

Agreed on the distinction. The wrappers that survive aren’t the ones with prettier docs — they’re the ones where the API isn’t actually the product. Auth, reliability, billing, opinionated workflow: those are real surfaces that don’t disappear when an agent shows up. If anything, agents make them more valuable, because the agent doesn’t want to handle retries, rate limits, or per-tenant billing logic either.
The “too early” point is fair and I’d push it further: MCP is distribution, not validation. Adding an MCP server to a product nobody pays for just gives you a more efficient way to deliver something the market already rejected. The sequence has to be value first, then surface. I think the trap a lot of teams will fall into is treating “we have an MCP server” as a wedge, when it’s really just a channel.
So roughly: if your moat is the API, MCP commoditizes you. If your moat is everything around the API, MCP amplifies you. The hard part is being honest about which one you actually are.

Good question and I think it’s the right one to be asking now, because the answer shapes what you build for the next few years.
My working line: MCP semantics own the verbs, the UI owns the nouns the human still needs to see and feel.
A verb is a decision the agent can make on the user’s behalf with enough context — publish, duplicate, route, classify, reconcile. These belong in MCP because the value comes from the agent doing them without round-tripping through a human. If the agent has to ask the user “are you sure?” for every step, you’ve just rebuilt the dashboard with extra latency.
A noun is something the human needs to perceive directly — a form preview, a chart, a table of incoming responses, the visual layout of a document. The agent can describe these, but description loses fidelity fast. A user looking at their published form wants to see it, not be told about it. UI is still the right surface for anything where the human’s eye is doing work the agent can’t do for them.
The interesting middle layer is review and correction. When a human edits something the agent produced, that edit carries information the agent should treat as authoritative going forward. That’s what I meant by protected state — it’s not really UI and not really MCP, it’s the contract between them. I think this is the layer most teams will underbuild. The agent generates, the human corrects, and if those corrections don’t flow back into the semantic layer, you end up with an agent that keeps making the same mistake confidently.
So long-term: MCP for action, UI for perception, and a deliberate handoff layer for judgment. Teams that treat MCP as a replacement for UI will overbuild on the agent side and frustrate users. Teams that treat MCP as just an API channel will underbuild on semantics and lose to ones that didn’t.

That collapse from save+format+send into save-to-inbox-as-mail is the whole game. Once the operation matches the user’s mental verb, the prompts get short and the model stops needing to be told the rules. You internalized the lesson faster than most.
On the override visibility question — I land on visible, but quietly. My reasoning:
If the override is invisible, two bad things happen. The user forgets they protected it and gets confused later when the agent “ignores” what looks like a normal item. And the agent’s behavior becomes legible only to whoever wrote the rule, which breaks trust the moment another teammate or a future-self looks at it. Hidden state is fine for infra. It’s poison for anything the user is making decisions against.
But you’re right that a loud “PROTECTED FROM AUTO-RUNS” badge is clutter. The compromise I use: a small, low-contrast indicator (a subtle dot, or a muted icon) on the item itself, plus a single sentence in any place where the agent reports what it did or skipped. Something like “skipped 3 items you’ve manually corrected.” That way the indicator is ambient when the user is browsing, and explicit when the agent’s behavior would otherwise look arbitrary.
The principle behind it: the user doesn’t need to see the protection at all times. They need to see it the moment the agent’s behavior would otherwise be a mystery. Show it where confusion would happen, hide it where it wouldn’t. That usually resolves the honesty-vs-clutter tradeoff in both directions at once.

You named the part most teams miss. The schema isn’t documentation that lives next to the product — it is the product, from the agent’s point of view. Every word in that description is in the planning context whether you want it to be or not, so the choice isn’t “do I write a description,” it’s “do I write the one that does work or the one that just labels the endpoint.”
The list_responses example is exactly the right shape. The second version doesn’t just describe the call, it tells the agent which questions are already answered. The model doesn’t need to plan a “first check if filtering is applied” step, because the description has already promised that it is. Three inference steps collapse into zero. Multiply that across a 115-tool surface and the difference between a server that feels sharp and one that feels like the agent is groping around becomes almost entirely a description-quality problem.
Your second point is the one I’d put on the wall. Storing correction_locked in the database is the easy half. Returning it as a typed field on the response, with a description that tells the agent what the flag obligates it to do, is the half that actually changes behavior. Prompt wording in a system prompt is hope. A schema field is a contract. And contracts survive chain depth in a way that hopes don’t — by step four or five of a multi-step plan, system-prompt instructions have been diluted by intermediate tool outputs, but a flag that comes back on every relevant response keeps reasserting itself.
The way I think about it now: the schema is where the product’s worldview becomes machine-readable. Anything important that only lives in the database, or only lives in the system prompt, is a leak. The first leaks because the agent can’t see it; the second leaks because the agent forgets it. The schema is the only surface where product knowledge stays both visible and durable across a long chain of reasoning. Teams that internalize that early will end up with MCP servers that feel like they understand the domain. Teams that don’t will end up rewriting their system prompts every time a new failure mode shows up — which is exactly the work the schema was supposed to absorb.

Yes, that’s exactly the tension I’m thinking about.

I don’t see FORMLOVA as only a “form tool” long term. The form is the entry point, but the bigger idea is to become a workflow and orchestration hub around form-based intent.

A form submission is often the first structured signal from a customer, lead, partner, or spammer. If the MCP layer can understand that signal, classify it, route it, and trigger the right next step, then the product surface becomes much larger than the form itself.

So I’m not too attached to “form” as a narrow category. I see it more as the starting surface for intent capture. FORMLOVA can stay as the abstraction, while the MCP semantics evolve around workflows, routing, classification, and decision-making.