Model Context Protocol (MCP): a standard way for an AI app to call another program

Why an interface was needed​

Before a common protocol, every assistant and every data source needed its own integration. Ten assistants and ten sources meant a hundred connectors, each with its own authentication, its own idea of what a “document” is, and its own way of describing a tool to a model. MCP collapses that: one server exposes tools once, and any compliant client can call them.

The shape is small. A server publishes a list of tools, each with a name, a description and a JSON Schema for its arguments. A client — the assistant — reads that list, decides which tool answers the user's request, and sends the arguments. The server executes and returns text, structured data or images. There are also resources (things to read) and prompts (canned jobs a user can pick from a menu), which is why an assistant can offer you “Proofread this document” as a command rather than hoping you phrase it that way.

Two consequences follow from that design, and both matter more than the plumbing.

The model chooses, so descriptions are prompts. A tool's description is read by the model, not just by a developer, and it competes with every other tool in the list. A vague description gets the wrong calls; an over-eager one gets calls nobody asked for.

The server is the security boundary. MCP has no notion of “this tool may not delete”. It describes capabilities; the server decides what to expose, to whom, and whether an action needs a human. An MCP server that hands out a shell is not a protocol flaw — it is a design choice, and the protocol will faithfully deliver it.

Where MCP gets hard in practice​

A file path is not a library. The most common MCP server for knowledge work exposes “read this file” and “search this folder”. An agent given those can open what it can find, but a 500-page book becomes a wall of text with no structure, and a question spanning chapters has nothing to navigate by. The interface is fine; the material behind it is thin.

Permission does not travel with the connection. The protocol has no vocabulary for “propose a change and wait for approval”. Either the server implements that as a separate tool, or the agent writes and the user finds out afterwards.

Local and remote are different promises. A server on 127.0.0.1 keeps the data on the machine. A server reachable over HTTPS, used by a hosted assistant, means the assistant's provider relays the requests — and the material with them. Both are legitimate; they are not the same claim, and marketing that uses “MCP” for both is where most confusion starts.

Tool lists grow. Every connected server adds tools to the model's context and to its choice. Past a few dozen, calls get vaguer and cheaper to get wrong. Curating the list is part of designing the server, not an afterthought.

How MindMax handles it​

MindMax runs an MCP server inside the desktop app, on the loopback address, so an assistant on the same computer can work against the folder you have open. The design takes the three hard parts above as the actual product:

• The library, not the file path. A long document is offered as a map — chapters, notes, section ids — so an agent navigates instead of skimming. See how the connection works.
• A review gate in the tool set. Changes to what you wrote are proposed, shown as tracked changes, and written only when you accept. New files can be created; nothing is overwritten or deleted — the mechanism is on edits wait for you.
• Local by construction. There is no remote endpoint, and no MindMax model is called on this path, so neither your files nor your credits leave the machine. The setup steps are in connect an AI app, and the tool list in the agent tool reference.