MKLab · tech talk
Understanding MCP
How the Model Context Protocol connects AI assistants to real systems, and when an MCP server beats a script.
Space to begin
I · The gap
Your assistant cannot reach your systems.
An assistant can be taught with instructions and skills and still answer only from what is inside the conversation. The ticket board, the staging database and the internal wiki all live outside it. Something has to carry live systems into the conversation, safely and on request.
II · The harness
Every assistant lives in a harness.
The harness is the application around the model: an IDE, a terminal, a chat app. The MCP specification calls it the host. It reads your configuration, discovers your registered MCP servers, hands your prompt to the LLM along with a catalog of their tools, executes the calls the model asks for, and streams the answer back. The model never touches your systems. The harness does.
III · An open, living standard
A protocol that keeps moving.
MCP started at Anthropic in late 2024 and now lives with the Linux Foundation, adopted by every major vendor. The specification's home is modelcontextprotocol.io, published as dated revisions. The latest, 2026-07-28, made the protocol markedly simpler: stateless, sessionless, a cleaner request flow. Expect it to keep moving.
IV · The orchestration loop
What actually happens.
The harness starts, discovers its MCP servers, and, in most harnesses today, loads every tool catalog into the context, needed or not: a real difference from skills. Your prompt goes to the LLM together with that catalog. The model picks a tool, and the harness makes the call: no MCP server ever talks to the model directly. The result goes back into the context, the loop repeats, and the answer streams to you.
V · Local MCP servers
A local MCP server is a process.
A local MCP server is a program on your own machine, started by the harness and spoken to over stdio. Your filesystem, your credentials, your laptop doing the work. Nothing is hosted anywhere. In practice: scripts behind a standardized contract.
VI · Remote MCP servers
A remote MCP server is a service.
A remote MCP server is an HTTP service with real authentication, and someone has to host it: you, your platform team, or a vendor offering it ready-made. One deployment serves everyone and credentials live centrally, but it is infrastructure, with uptime, upgrades and a security surface of its own.
VII · MCP server or skill
The same loop, two contracts.
A skill with local scripts produces the same orchestration: the model decides, code runs, results come back. The skill loads progressively and costs almost nothing until used. A local MCP server typically preloads every tool schema and adds a moving part. Our recommendation: building a local MCP server yourself rarely buys what a skill with scripts already gives you. MCP shines when the MCP server is provided for you.
VIII · When to use what
A simple rule.
Use MCP when someone else implements the MCP server for you. Write a skill when you would have to implement it yourself. The honest exceptions: a harness that cannot run scripts, typed contracts you must rely on, or one integration a whole organization should share. Then an MCP server earns its place.
IX · Where this is heading
Remote, hosted, ordinary.
The direction of travel is hosted and leaner: an official MCP server registry, authentication built in, and clients learning progressive discovery and code execution so tool catalogs stop crowding the context. An extension for serving skills over MCP is on its way through standardization. The specification lives at modelcontextprotocol.io. Watch it, it moves.
MKLab · EST. MMXXV
That was MCP.
This is the end of the presentation. Thank you for watching. The talk on teaching your Copilot pairs well with this one.
