API, MCP or MCP App? Choosing the right surface for AI agents

AI-referred shoppers convert 54% higher and generate 53% more revenue per visit than non-AI traffic (Adobe, May 2026). AI sessions to retailers grew 138% year-over-year. As the customer journey collapses into a single conversation, “build an API” stops being the obvious answer when the consumer isn’t a developer but an agent.

This talk distills what we learned shipping to ChatGPT, Claude, and our own internal agents – and the framework we use to decide what to build for whom.

API, MCP, and MCP App are three different products serving three different consumers: a developer building their own integration, an agent runtime where the host owns the UI, and an app surface where the UI returns but is shared with the model. Treating MCP as a drop-in replacement for an API is how teams end up with a tool surface their agents can’t actually use.

From there, four engineering lessons stand out that don’t appear in the MCP spec:

– Tool descriptions are prompts, not docs. A one-line change can flip whether the model calls your tool, or calls it with hallucinated arguments.

– Flow is a design surface. You’re not designing tools in isolation – you’re designing the path the model walks through them.

– Treat your tool surface like a prompt: version it, snapshot it, eval it. Unit tests don’t catch the failures that matter.

– In an MCP app, the UI is part of the prompt. Widget state pushes back to the model as context; tools split between model-visible and widget-only – a new design discipline with little prior art.

Attendees leave with a decision framework for the three-way call, and a practical checklist for shipping a tool surface that agents can actually use.