Explainers · Model Context Protocol
What is an MCP server? A plain-English guide.
An MCP server is a small program that gives an AI agent new abilities (reading your files, querying a database, searching the web) through one shared protocol. The model decides when to use them; the server does the work. It is the piece that turns a chat box into something that can act on your machine. Here is how it works, end to end, and why the humblest capability of all, finding a file, is the one every agent needs most.
The one-sentence version: an MCP server is a tool an AI agent can call, a standard adapter that lets any agent use any capability without a hand-written integration for each one.
The core idea
An agent, a server, and one handshake.
Model Context Protocol (MCP) is an open standard: think of it as a universal port for AI tools. On one side sits the agent (the app plus the model). On the other sits a server offering a menu of tools. The agent reads the menu, the model picks a tool when it needs one, the server runs it and hands back a result. That round trip is the protocol. Everything else is detail.
Connect·The moment an agent launches (Claude Code, Cursor, or any of the others) it opens a connection to each MCP server and asks a single question: what can you do?
Advertise·The server replies with a menu of tools. A file server offers four: iFileNames, iFileText, iFileSearch, iFileKnowledge, each with a plain-language description the model can read and reason about.
Decide·You ask the agent something real: “where’s the auth config?” The model reads the menu, decides a tool fits, and emits a structured call, e.g. iFileNames(“auth config”).
Execute·The server runs the call against its own resource (here, an always-fresh index of every file on the machine) and hands back a precise result. No filesystem walk, no shell process.
Answer·The model reads the result and replies. It never crawled your disk; it asked a tool that already knew. That five-step loop is the entire Model Context Protocol.
Notice the split in the diagram: MCP standardises only the agent ↔ server link. What the server does on its own side (files, a database, the web) is up to the server. That separation is the whole trick: the agent never has to know how the tool works, only how to ask.
Why it exists
One connector, not a drawer of adapters.
Before MCP, a tool maker wrote a separate integration for every app: one for VS Code's extension API, another for Cursor, another for each terminal agent. Apps times tools is a lot of glue, most of it never written. MCP collapses that: a tool speaks the protocol once, and every app that speaks MCP can use it. It is the same idea as USB-C: one shape instead of a box of cables.
The payoff for you is direct: install a capability once, and every agent on your machine gets it: no per-app plugins to build, no per-app plugins to maintain when the next agent ships.
In the wild
Databases, browsers, files. and the two agents that made it mainstream.
MCP servers already exist for almost anything an agent might want to touch. And the two agents most people reach for both speak MCP natively: Claude Code, Anthropic's terminal agent, and Cursor, the AI-native IDE. Add a server once and both pick it up, as does every other MCP client on the machine.
Of every capability an agent can be handed, the one it reaches for constantly is the plainest: where is that file, and what's inside it? An agent that can't find things fast can't do anything fast. And it all runs locally: no cloud, no network port, nothing leaves your machine.
The file-search MCP server
Interlinked Files is the MCP server for your whole machine.
It exposes four tools (filename search, content search, both at once, and a knowledge lookup that returns everything known about one file, folder, or repo), backed by an always-fresh index of every file on your PC: every repo, every document, even the git-ignored files a project-scoped search never sees. Claude Code and Cursor call it exactly the same way. One install configures 19 AI clients at once. And it answers at a speed a shell command can't reach, measured on a real 4.47-million-file machine. Save a file and it's searchable again in about a millisecond, so the answer is never stale. Every hit can even carry a short note a past agent left on that file: knowledge that rides along on the search.
IT'S NOT A SMARTER MODEL. IT'S A FASTER FLOOR UNDER EVERY AGENT YOU ALREADY RUN.
Measured, not claimed
What “instant” actually buys.
| The searcher | What ran | Time | vs Interlinked |
|---|---|---|---|
| Interlinked Files | one indexed filename lookup | 85 µs | baseline |
| VS Code (Ctrl+P) | same file, same drive | 35 s | 412,000× |
| Windows Search | median of 20 queries | 67 s | ~480,000× |
| ripgrep | same content query, same corpus | 93.8 s | 58,625× |
| Claude Code (no index) | one file, agentic archaeology | 3 m 13 s | 2,276,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename lookups are microsecond-scale (85 µs single, 139 µs median of 20 queries). The ripgrep row is the same content query, content-to-content (93.8 s → 16 ms; 58,625× across the five-query set). The Claude Code row is a measured single-file agent run: the agent, given no index, listing directories until it stumbled on the file.
Do this today
Give every agent the file layer.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing, no per-app setup.
Let it index. Filename search works immediately; content search fills in behind it. At rest the whole engine sits around 44 MB, less than a browser tab.
Ask normally. Your agent picks the right tool by itself. You just ask where something is, or what mentions it; the answer comes back in microseconds, whole-machine.
It stays fresh. Save a file and it's searchable in about a millisecond, under 30 in the worst case. The index rides your changes; you never re-index by hand.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.