Letting AI Interface with Your App with MCP

What can Tony Stark ask Jarvis to do that an AI assistant cannot do today? Kent C. Dodds opens with that question as a product-design exercise: if users increasingly interact through assistants, applications need a way to meet them there. The Iron Man scene supplies a concrete benchmark for the experience.

Jarvis begins by compiling records from SHIELD, the FBI, and the CIA, then reconstructs a crime scene. The fictional evidence includes a blast exceeding 3,000°C, vaporization within 12.5 yards, and no bomb parts within three miles of the Chinese Theater. These are inputs to the scene’s investigation, not measurements of an AI system.

Tony asks whether there were military victims; Jarvis checks public records. Tony then asks for thermogenic signatures, factoring in the blast temperature. Jarvis plots the previous twelve months of occurrences, and Tony asks it to remove locations associated with Mandarin attacks. The remaining evidence points toward military victims and Tennessee. A conversational question about Tennessee becomes a flight-planning action.

The compelling feature is the continuity between those operations. Jarvis gathers data, generates an interface, accesses records, joins datasets, brings up related news, and creates a flight plan without making Tony move context between applications. It also identifies a visitor at the door—an expansive use of personal information that prompts Dodds’s privacy joke. The benchmark combines retrieval, presentation, and action in one interaction.

Some parts of the scene remain out of reach for reasons beyond software integration. Access to restricted agency records is not simply a technical problem, and the holographic interface remains a separate challenge. Generating a useful interface, however, is already possible. Nor must an assistant be voice-only: Tony combines speech, typing, gestures, and direct interaction with generated displays. In a shared office, a quiet interface may be the better experience.

Integration coverage is the practical bottleneck. An assistant can be useful across many familiar services and still fail on the one task a user actually needs. Dodds’s example is reserving a pavilion through a local government website. A major assistant vendor is unlikely to build that particular integration, yet the user still wants the assistant to handle it.

Rare tasks make bespoke setup especially unattractive. If you will use a service once, wiring it into your assistant may take more effort than completing the task yourself. Learning an unfamiliar website is also a cost. Model Context Protocol, or MCP, offers a standard way for assistants to communicate with tools and services, making that integration reusable rather than a separate project for each assistant.

Dodds traces the architecture through three phases, beginning with ChatGPT as a question-answering application. The crucial distinction is between the LLM and the host application surrounding it. The model generates responses, sometimes incorrectly; the host makes interacting with that model accessible. Dodds attributes ChatGPT’s impact to that user experience and the investment it subsequently attracted, rather than to the mere existence of a language model.

In this first phase, the user transports both the context and the result. To request a refactor, you copy code into chat, ask for changes, and paste the answer back into the codebase—where you may discover another problem. Adding image inputs expands what you can supply, but does not remove the manual work or the context-window constraint. The application answers questions without carrying out the corresponding work in your other applications.

The next step follows from a simple observation: the host is ordinary software. It can tell the model which operations it supports, obtain more context when the model requests it, and execute application actions. Search supplies information; a calendar integration schedules a meeting; a Slack integration provides messages to summarize. Tool use connects a model’s request to code that can actually do something.

That still leaves every capability dependent on someone building the integration. The assistant vendor’s engineering time determines both the available actions and the available context sources. A municipal reservation system remains unlikely to reach the top of that backlog. Platform-specific integrations—the proprietary GPT plugin approach in Dodds’s historical comparison—also require service developers to justify separate work for each assistant ecosystem.

A service can instead build its own host application, with its own tools. But each wrapper becomes another destination the user must supply with context. Moving from one specialized assistant to another recreates the copying problem at the application level. The desired experience is one assistant that can acquire additional capabilities, rather than a collection of assistants that each know only part of the task.

MCP moves the integration boundary. A service provider implements a shared protocol, and supporting assistants can connect through it. Dodds describes universal assistant support and a Jarvis-like experience as the direction of travel, while explicitly acknowledging that clients were not yet ready for that experience at recording time. Interoperability still depends on the capabilities a client and server support and the permissions the host grants; implementing MCP does not make every feature available everywhere.

The host continues to communicate with the model. It supplies the currently available services and the user’s request, allowing the model to select an appropriate tool. Services can be added or removed, so the host also manages which capabilities appear in the model’s context. The model does not need a permanent, exhaustive list of every service it might ever use.

The MCP architecture separates those responsibilities:

The host creates a client for each server connection. The service provider owns the server and the behavior behind it. Tools, resources, and prompts are server capabilities; sampling lets a server request model generation through a client that supports it. Those capabilities extend beyond the tool calls shown in the demonstration.

Standardize the connection; keep application behavior with the service provider. The assistant developer need not write a bespoke connection for every application, and the application developer remains responsible for what its service actually does. That division is how MCP gives the assistant a way to act across independently built services.

The demonstration uses Claude Desktop configured with three MCP servers. Dodds asks it to write a journal entry about a trip with his daughter, supplies his email address, and asks it to derive location and weather from the device’s location. He explicitly requests a creative story with relevant tags, so the resulting entry is intended to be fictional. This is a configured desktop workflow, not yet the seamless interaction of the opening film.

The first call goes to Locationator, which determines the current location. Dodds permits its use for the current chat. That approval is a visible part of the workflow: unlike Tony’s trusted relationship with Jarvis, this assistant asks before using capabilities. Dodds expects reliability and trust to change that experience over time; the demonstration still includes the permission prompts. The returned location is his London hotel, not his home.

Next, Get Weather uses the location’s coordinates to obtain current weather. The output from one service becomes the input to another, before the assistant moves on to the journaling service, Epic Me. The user states one goal; the assistant coordinates the separate capabilities needed to satisfy it.

Epic Me cannot yet perform the authenticated journal operation, so the assistant invokes its authentication tool. The visible login sequence is:

1. Provide Dodds’s email address to Epic Me.
2. Obtain the validation token. For this local demonstration, Dodds reads it from the console instead of opening his email.
3. Submit the token to validate the login.

The response confirms successful authentication.

Dodds connects authentication to OAuth 2.1, but the email-token interaction shown here should not be confused with a complete transport-authorization flow. The March 2025 authorization specification defines optional HTTP authorization based on the OAuth 2.1 draft; it does not make every MCP server automatically authenticated or secure. In the demonstrated workflow, the consequential transition is that the client can now perform authenticated tasks, including creating a journal entry.

The model writes the fictional entry for convenience. The same application capability could accept text the user wrote, or an assistant could format spoken dictation before saving it. The server’s journal operation need not change simply because the user chooses a different input modality.

Epic Me defines the inputs for creating an entry, and the assistant uses the gathered information to populate them. It then checks the available tags. A travel tag is missing, so it creates one and attaches it to the entry. This is another small sequence of application operations driven by the original request, rather than a single text-generation response.

Dodds next asks to see the entry. The assistant retrieves the saved title and contents, then presents them in a more readable form than the server’s JSON. A minimal example of that data shape, using illustrative journal text, is:

{
  "title": "A day in London",
  "contents": "My daughter and I explored London together."
}

The client can turn title into a heading and contents into body text. The server supplies structured content; the assistant and host determine how the user sees it.

The demonstrated presentation is Markdown with a title. Dodds extends that idea to dynamic cards and interactive interfaces, while noting limited client support at recording time. He also proposes a language boundary: a server could return English while an assistant presents the response to a Japanese-speaking user in Japanese. The recording shows formatting; richer interfaces and translation are possibilities he describes, not additional completed demonstrations.

To finish the demonstration, Dodds asks the assistant to delete the fictional post and log him out. Cleanup uses the same interface as creation and retrieval. Epic Me is accessible through MCP clients rather than through a user-facing web application: its product capabilities exist without requiring users to visit a dedicated website.

That design leads to the broader product question. Dodds recalls teaching his parents to search the web: they naturally typed full questions, but had to learn keyword phrasing to obtain better results. An assistant reverses that accommodation. The user describes an intended outcome, and the software works out both what information is needed and what action to take. Dodds predicts that this will move more interaction away from browsers; it is a product direction, not proof that every user or task will abandon the web.

The implementation starting point is the MCP specification; Dodds also points to Epic AI for MCP education and writing about changing user interaction. For an application developer, the opportunity is to make the service’s capabilities available inside the assistant where a user is already expressing what they want to accomplish.