MCP Is Coming to Your Desktop Applications

When developers hear Model Context Protocol (MCP), the mental picture is usually a server.

An MCP server exposes tools or resources. An AI agent connects to it and suddenly gains access to a database, a source-code repository, a documentation system, a browser, or some corporate service.

That is an important use case for MCP, but I think it hides another one that may eventually become much more visible to ordinary users:

Desktop applications can expose themselves through MCP.

The application does not need to contain an LLM. It does not need to implement an agent. It does not need its own chat interface. It only needs to expose the right capabilities. The agent may already be sitting somewhere else.

I recently implemented this idea in Diptych, a macOS file manager, and the experience changed the way I think about MCP.

Diptych in a Nutshell

Diptych is an open-source, native macOS two-pane file manager written in Swift and SwiftUI.

The concept is deliberately traditional: two directories side by side, keyboard-oriented navigation, copying and moving between panes, rename, permissions, Quick Look, directory comparison, text and binary editing, undo, and the other operations expected from this style of file manager.

The project is available on GitHub: https://github.com/verhas/diptych.

But this article is not really about Diptych as a file manager. It is about what happened when I gave an ordinary personal productivity application an MCP interface.

We Usually Think of MCP as a Server

Technically, Diptych does contain an MCP server. It listens locally and provides an interface through which an MCP-capable agent can interact with the running application.

But describing it simply as an "MCP server" misses the interesting part.

Diptych is not a server application. It is not a multi-user service sitting somewhere on a network waiting for clients. It is an ordinary application used by one person on their Mac. 

You launch it. You browse directories. You select files. You open windows. You compare directories. You copy, rename, and move things.

MCP is simply another interface to that same running application. Through MCP, an agent can ask questions such as:

• What windows are open?
• Which directories are displayed in the two panes?
• Which pane is active?
• What files are selected?
• What is currently being compared?
• What options were used for the comparison?

It can also interact with the application: change the active pane, select files, open comparison or information windows, change selected settings, and propose batches of file operations.

This is MCP used as a personal productivity interface.

But those MCP functions are implementation details. They are not what makes the feature interesting to the user. What matters is what I can now ask my agent to do.

For example:

Select the three largest archive files that are older than one week and have not been accessed for at least three days.

I can do this manually in a file manager, of course. I can sort files, check their sizes and timestamps, identify archives, and select the appropriate files.

Or I can express my intent in one sentence.

I do not even have to specify that an archive might mean .zip, .tar.gz, .7z, or some other format. The LLM already understands what an archive is. Through MCP, it knows which directory I am working in; it can inspect the files and their metadata, reason about size, modification, and access times, and tell Diptych which files to select.

The result is still visible in the ordinary Diptych GUI. I can see exactly what the agent selected before doing anything with those files.

I can go one step further:

Select the three largest archive files older than one week that have not been accessed for at least three days, and delete them.

Now the request has a destructive consequence, so the interaction changes. The agent can determine which files satisfy the request, but it does not silently delete them. Through MCP, it proposes the deletion operations to Diptych. Diptych presents its normal confirmation window with the concrete files about to be deleted.

I inspect the list and approve it. (Or not.)

Only then does Diptych perform the deletion.

This illustrates the division of responsibilities particularly well: the LLM understands what I mean, MCP connects that understanding to the application, and Diptych remains in control of what actually happens to my files.

And I think that use case deserves much more attention.

Do Not Put the Agent Into Every Application

When adding AI functionality to an application, the obvious architecture is something like this:

Application
├── UI
├── Business Logic
├── LLM API
├── Agent Loop
├── Tool Calling
└── Prompt Management

The application becomes responsible for implementing an AI subsystem.

It has to choose a model provider, manage prompts and context, implement tool calling, handle agent loops, manage authentication and API keys, and probably provide some sort of chat interface.

Then the next application implements much of the same machinery again.

But why?

The user may already have an agentic system capable of reasoning, planning, maintaining context, asking questions, and calling tools.

If that is the case, the architecture can be much simpler:

User  | Agentic System  | MCP  | Application

The application does not have to become an AI application.

It only has to become agent-accessible.

That is a fundamentally different approach.

The Agentic Functionality Is Already There

This was perhaps the most important realization for me while implementing MCP support in Diptych.

If I wanted "AI-powered file management," I could embed an LLM into Diptych.

I could put a text field somewhere saying:

What do you want to do?

Then Diptych would have to send that request to a model, provide context, define tools, process tool calls, maintain a conversation, handle failures, choose models, configure credentials, and keep adapting as the AI ecosystem changes.

But if the user already has an agentic system, all of this is unnecessary.

The agentic functionality is already there.

Diptych only needs to provide the application-specific part that the external agent cannot provide itself.

It needs to say:

Here is what I know.

and:

Here is what I can do.

That is MCP. The agent supplies the intelligence. Diptych supplies its capabilities and application state. MCP connects them.

Why Not Just Let the Agent Use the Shell?

For a file manager, there is an obvious objection. An agent can already manipulate files through shell commands. Why does it need Diptych?

Because Diptych knows something the shell does not: what the user is doing right now.

Imagine that I have two directories displayed in Diptych. I have selected four files in the left pane. The right pane shows another directory. Perhaps I also have a directory-comparison window open with specific comparison options. The operating system knows about all these files. But it does not know that these particular directories and files currently form the context of my work. Diptych does.

That means I can say to an agent:

Compare these two directories, including permissions and extended attributes.

Or:

Select the files that exist only on the left.

Or:

Move these files to the directory in the other pane. (F6)

The word these suddenly has meaning.

The MCP interface gives the agent access not merely to filesystem functionality but to interactive application context.

That is easy to overlook when MCP is considered purely as a protocol for backend services.

MCP as Another Application Interface

We already accept that an application may have several interfaces. A graphical interface exposes capabilities to a human using a mouse and keyboard. A command-line interface exposes capabilities to shell users and scripts. A scripting API exposes capabilities to automation. An MCP interface exposes capabilities and context to an agent.

Seen this way, MCP becomes something larger than a mechanism for connecting an LLM to servers. It can become an agent-facing application interface. And once you look at it that way, there is little reason to restrict it to developer tools, databases, or enterprise infrastructure.

Personal MCP

Imagine ordinary desktop applications exposing interfaces like these:

Mail    search_messages    get_selected_thread    draft_reply 
Calendar    get_visible_week    find_free_time    propose_event 
Image Editor    get_current_document    get_selection    resize_selection    export_image 
IDE    get_open_files    get_current_selection    run_tests    show_diff 
File Manager    get_pane    get_selection    compare_directories    propose_file_operations

None of these applications needs its own LLM. None needs its own general-purpose agent. And perhaps none needs yet another little "Ask AI" button. They need a vocabulary through which an agent can understand what they know and what they can do. The user can then choose the agentic system. The applications provide capabilities.

Applications No Longer Need to Integrate With Each Other

This becomes even more interesting when several personal applications expose MCP.

Imagine telling an agent:

Find the PDF invoices I downloaded last month, move them into the accounting folder, attach them to a draft email to my accountant, and show me the draft before sending anything.

Several applications may be involved. The file manager understands the filesystem and the user's current file-management context. The mail application understands messages, recipients, drafts, and attachments. Another application may understand the contents and metadata of the PDFs.

Traditionally, these applications would need explicit integrations with one another. Application A needs an API for application B. Someone has to implement that integration. Then perhaps B needs integration with C.

With an agent in the middle, the architecture can look very different:

             Agent
           /   |   \
         MCP  MCP  MCP
         /     |     \
File Manager  Mail  Calendar

Applications don't need to know anything about one another. They simply expose their capabilities. The agent performs the orchestration. That is almost an inversion of traditional application integration.

The Security Boundary Still Belongs to the Application

This creates an obvious danger. If an agent can operate applications, it can also make mistakes at machine speed.

MCP should therefore not mean:

Agent says something
        ↓
Application obeys

Diptych deliberately does not work that way for potentially destructive filesystem operations.

An agent can propose a batch of operations. Diptych presents the concrete operations in its own native UI. The user can inspect them, modify individual operations, deselect some, approve them, or cancel the whole batch. In addition, Diptych keeps track of a long undo list, and most operations can be reversed.

The agent may interpret:

Move the old log files to the archive and make them read-only.

But before execution, the application can show concrete operations such as:

MOVE   server-2025.log        → archive/server-2025.log
CHMOD  archive/server-2025.log → r--r--r--
MOVE   audit-2025.log         → archive/audit-2025.log
CHMOD  archive/audit-2025.log  → r--r--r--

The user approves operations, not merely the agent's interpretation of the request. That separation matters.

The agent is responsible for reasoning. The application remains responsible for defining what operations are possible, validating them, enforcing authorization, and ultimately controlling execution.

MCP does not remove the application's security boundary. If anything, agent access makes that boundary more important.

The GUI Is Not Going Away

None of this means that agents should replace graphical interfaces. Looking at files visually is useful. Comparing directories visually is useful. Editing an image visually is essential. Viewing a week as a calendar can be much more useful than asking an agent about every appointment.

What changes is that the GUI is no longer necessarily the only interface through which intent enters an application.

Today, we mostly have:

Human → GUI → Application

Increasingly, we may also have:

Human → Agent → MCP → Application

And frequently both at the same time.

I can manipulate files directly, ask the agent to perform something tedious, inspect its proposed operations in Diptych, change something manually, approve the rest, and continue working.

The agent does not replace the GUI.

It becomes another way of controlling it.

Applications as Capability Providers

This suggests a design principle that I think may become increasingly important: Do not necessarily put an agent into your application. Make your application usable by agents.

The distinction sounds subtle, but architecturally it is substantial. Embedding an agent couples an application to a rapidly changing AI stack. Providing MCP describes what the application knows and what it can safely do. That is much closer to the application's real responsibility.

A file manager should be exceptionally good at manipulating files. A calendar should be exceptionally good at managing calendars. An image editor should be exceptionally good at editing images. The agent should be good at understanding what the user wants and coordinating those capabilities.

Where This Is Going

Diptych is, as far as I can determine, among the first native macOS personal productivity applications to expose its live GUI state and application capabilities through MCP.

That distinction matters. File-oriented MCP servers and even multi-user file-management applications already expose MCP. But that is still close to the way we usually think about MCP: a service provides capabilities and an agent connects to that service.

Diptych represents a somewhat different model. It is an ordinary, single-user desktop application. You launch it, see two file panes, select files, open windows, compare directories, and perform operations just as you would with any other macOS productivity application. MCP is simply another interface to that same running application.

The agent is not built into Diptych, and Diptych is not primarily an MCP service. It is your application, exposing itself to your agent.

I think we will see much more of this. Today MCP discussions are dominated by servers connecting agents to developer tools, databases, web services, and enterprise systems. Tomorrow, MCP may increasingly become an interface to the applications already running on our personal computers.

Your file manager exposes MCP. Your mail client exposes MCP. Your calendar exposes MCP. Your IDE exposes MCP. Your image editor exposes MCP.

These already exist. None of them needs its own LLM or an agentic system. They expose their state and capabilities, while the agent you already use supplies the reasoning and orchestration.

Eventually, you might tell your agent:

Put these files into the project archive, attach the report to the email we were discussing, and move tomorrow's meeting by half an hour.

The agent may accomplish that by talking through MCP to three independent desktop applications. Those applications do not need integrations with one another. They don't even need to know the others exist. They simply expose capabilities.

The agent provides the intelligence. MCP provides the common interface. Diptych is a small example of this model today. I expect it to become a standard feature of desktop applications in the future.

Perhaps, a few years from now, asking whether an application supports MCP will be as natural as asking today whether it has an API, plugins, or a command-line interface.