A MotorTrack user — a product I design and build — was already used to conversing with ChatGPT for other purposes. One day, after a connection step for which she needed a bit of technical assistance from me, she consulted and updated her MotorTrack data directly from that same conversation — no new screen, no new tool to learn.
This observation, isolated but concrete, reveals a shift in where the difficulty sits: day-to-day use becomes natural, while the initial connection still requires hand-holding.
The MotorTrack case
MotorTrack exposes an MCP (Model Context Protocol) server: a standardized access point that the conversational assistant can query to look up or change certain data, within the limits of the authorized tools. From the user's side, this integration showed up as a connected app in ChatGPT — technically, a custom MCP connector, added through developer mode, since MotorTrack isn't listed in the public directory yet.
Setup required assistance: configuration, authorization, a bit of technical vocabulary. Once past that step, usage went back to being what it already was for her — a conversation. She didn't have to relearn an interface; she kept doing what she already knew how to do, over a wider set of data.
This observation remains isolated. It doesn't prove this mode of use is spreading — it documents one case where it worked, and where the nature of the friction clearly shifted.
App, connector, MCP: why the words blur the lines
The vocabulary doesn't make things easier, and it keeps shifting. A few reference points, as of now:
- integration — the neutral term I use in this article to refer to the whole thing;
- plugin — since July 2026, the main space where ChatGPT and Codex surface their capabilities: a plugin can bundle one or more apps, skills, or app templates;
- app — the integration itself, the one that connects ChatGPT to an external service to look up information or carry out an action;
- MCP connector — a term used in some technical contexts to designate a custom app built on an MCP server;
- MCP — the underlying technical protocol, when it's actually what powers the integration;
- MCP server — the service that exposes the connected application's capabilities;
- MCP tool — the precise operation that server offers the assistant: looking up one piece of data, changing another.
These terms aren't interchangeable: a plugin can contain an app, but isn't necessarily one; an app can rely on MCP, but not every app depends on it. MotorTrack, here, is a custom app that does rely on an MCP server — the server it exposes is indeed an MCP server, and that protocol is what makes this app possible.
MCP was created by Anthropic in 2024. In late 2025, Anthropic transferred its governance to the Agentic AI Foundation, a dedicated fund under the Linux Foundation umbrella, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg — it's no longer a single vendor's proprietary technology (Anthropic announcement, Linux Foundation announcement).
What the user sees, what the developer builds
The user sees an app to activate; the developer relies on a protocol and builds a server along with the tools it exposes. That distance explains why usage, once the connection is made, feels so simple: the technical layer simply isn't visible anymore. This level of use — an external tool called under the user's direct instruction — matches what I describe elsewhere as a tool-using AI assistant, as opposed to an agent that would decide the sequence of actions on its own.
What two studies show — and don't show
The MotorTrack case remains an isolated observation. Two recent studies on conversational interfaces help put it in context, without directly validating it — neither one covers MCP adoption by business users.
The Voice CMS: updating the knowledge base of a digital assistant through conversation study compares a conversational voice interface to a classic graphical CMS. Useful result here: the conversational interface is preferred for simple tasks, with comparable input quality even on complex content. Limit: its overall usability remains lower than the graphical interface's — the authors recommend a hybrid approach, not a replacement.
The Neither Replacement nor Panacea: Comparing LLM-Based Conversational and Graphical Decision Support in Industrial Tasks study, conducted with 134 industrial decision-makers, observes reduced mental load and time savings on simple tasks. Limit: that advantage shrinks as task complexity grows, and the conversational interface isn't preferred as the sole decision-support surface.
Both studies converge on the same point: conversation mainly helps on simple tasks, and coexists with the graphical interface rather than replacing it. That's complementarity, not validation of the MotorTrack case — which remains a field observation, not generalizable proof.
What this changes
Three things stand out from this case:
Conversation becomes a new entry point into the business application — one more entry point, not a replacement. The graphical interface stays necessary for part of the usage, and for onboarding: that's precisely where the friction concentrated in the MotorTrack case. The real design question, for whoever builds this kind of product, isn't "conversation or graphical interface" — it's figuring out which actions are worth making accessible from a conversation, and which ones, on the contrary, are better left in a screen.
In MotorTrack's case, usage from ChatGPT turned out to be natural once the connection was established. The main difficulty was in the initial setup, which required assistance.
Personal account, based on MotorTrack's MCP server. The user mentioned stays anonymous.