What is the Model Context Protocol (MCP)?

The context

You already have a coaching conversation in one app. What you cannot do is ask the assistant you use every day - the one in your browser tab, the one on your laptop - a question it can answer with your actual training. It has never seen your Concept2 logbook. So it guesses, or it asks you to paste your splits, and you spend a Saturday morning retyping numbers your own app already holds.

That gap has a name, and the name is a protocol. The Model Context Protocol is an open standard for wiring an AI application to the systems where its data already lives [1] Specification 2026. Anthropic released MCP as an open standard in late 2024, built from three pieces - resources, prompts and tools [6] Anthropic 2024 - and it has spread well past the company that wrote it. The protocol's own documentation names Claude, ChatGPT, VS Code and Cursor among the applications that speak it, and gives the analogy that helps most people: MCP is to AI applications what USB-C is to devices, a standard socket instead of a bespoke cable for every combination [5] Introduction 2026.

The point of a standard is that nobody writes the wiring twice. Researchers working on the same problem describe the cost in the same terms: without one, every new assistant needs its own hand-built connection to every new tool, which is the interoperability bottleneck [9] Yue 2026. Once a data source speaks MCP, any compliant assistant can reach it - and the reviewer who published on the subject puts it plainly, that the value of MCP is in standardisation and discovery, because one implementation serves every MCP-speaking client instead of each one writing its own [8] Sheffield 2026.

For a rower that is not abstract. MyNextRow publishes its coaching engine as an MCP server: nine named tools that read your profile, your training load, your recent sessions, your streak and your credit balance, and that validate or generate a session. The laboratory version of the same idea is now ordinary practice - an agent system built for materials characterisation was made compatible with MCP so its instrument-control tools could be consumed or served by other applications, and the benefit its authors reported was less operational burden and a lower expertise barrier for the people using it [10] Du 2026. A rower should get the same thing: the assistant they already use, answering with their own numbers.

The core idea

Three parts, and the names matter because people mix them up.

The client is the connector the assistant owns. The specification's own picture has a host - the application you are talking to - create one client per server, each client holding a one-to-one relationship with a particular server [2] Architecture 2026. If your assistant talks to three different things, it runs three clients. You never see them; they are plumbing.

The server is the program that owns the data and the operations. Servers expose resources, tools and prompts as MCP primitives, and the specification is explicit that a server can be a local process or a remote service [2] Architecture 2026. The MyNextRow one is a small program on your own machine, and the protocol has a transport built for exactly that: over stdio, the client launches the server as a subprocess and the two ends talk over its standard streams [4] Transports 2026. A second transport exists for a server running somewhere else, where each message is an HTTP POST to a single endpoint [4] Transports 2026.

The tools are the operations the server publishes. Each one has a unique name and metadata describing its schema [3] Tools 2026, which is how an assistant knows that "what did I row last week" needs get_recent_workouts rather than get_training_load.

The other two primitives deserve a sentence, because Anthropic's announcement names all three. Resources are context and data a server makes available for the user or the model to use; prompts are templated messages and workflows a user can invoke [1] Specification 2026. The difference is what they do about it: a resource hands over data, a prompt hands over a suggested way of working, and a tool runs something.

What a tool is not: it is not a second model, and it is not the assistant's own knowledge. The assistant already knows how to explain interval training. A tool is the thing that knows your numbers, and it answers with a result the assistant then has to interpret.

MyNextRow's nine tools split cleanly. Seven are reads that cost no credits - get_athlete_profile, get_training_load, get_recent_workouts, get_technique_and_streak, concept2_connection_status, get_credit_balance and validate_workout. Two spend a credit - ask_coach and generate_workout - and if the call fails the credit is refunded.

The how-to

Here is what happens when you ask your assistant a question about your training, with no mystery in it.

1. The assistant asks what the server can do. A client sends a tools/list request and the server answers with the tools it publishes, each with a name and a schema [3] Tools 2026.
2. The assistant decides to call one. Tools in this protocol are model-controlled: the model can discover and invoke them automatically from the question and what you asked [3] Tools 2026. Step two is where the wording of a tool matters, because the assistant is choosing from the descriptions the server published. A tool named get_recent_workouts gets picked for a question about last week, and a tool that does two unrelated jobs gets picked for both.
3. The client sends the call. It is a tools/call request naming the tool and its arguments [3] Tools 2026.
4. The server runs it against the data your API key authorises and returns a tool result, with a flag for whether the call itself failed [3] Tools 2026.
5. The assistant writes the answer, in words, from the result it has just received.

Two things follow from step four, and they are the whole point.

First, the assistant cannot invent a tool result. The numbers in its answer came back from the server; the model is composing prose over a payload it did not write. When a call fails, the result says so - the protocol separates protocol errors from tool execution errors precisely so that the model can tell "that did not work" from "you asked wrongly" [3] Tools 2026.

Second, you can see what is on offer. The server's tool list is not a secret, and the specification expects applications to make clear which tools they expose to a model, to show a visual indicator when a tool runs, and to keep a human able to deny the call [3] Tools 2026. Its security section is blunter still: hosts must obtain explicit user consent before invoking any tool, and tools represent arbitrary code execution that has to be treated with appropriate caution [1] Specification 2026.

The trade-offs

What a local server gives you, and what it does not.

It puts your own machine in the loop. Over stdio the client launches the server as a subprocess [4] Transports 2026, so the server only runs while your assistant is running, and it reaches MyNextRow's API over the network with a single API key. The key is what authorises the calls: the server can reach the data your key reaches and nothing else. A peer-reviewed account of MCP describes it in the same terms - an MCP server is an application that runs locally or on the web and provides tools an LLM can invoke [8] Sheffield 2026.

It needs a runtime on your machine. The MyNextRow server is started with npx, so Node has to be installed and on your path. That is the price of the local part, and it is why the connection guide starts with the runtime rather than with the key. One more condition applies today, and it is not about your machine: the packaged server has not been published to npm yet, so npx cannot fetch it and the command fails with a 404 before it reaches anything else. The connection guide says so where you would look for it, and it is why the step below ends with a check rather than with a success.

It can fail quietly. A subprocess that dies takes its tools with it. The assistant is then left with no logbook to read, and may answer from its own training instead of saying that it cannot see your logbook. The protocol's answer is process hygiene - a server should exit when its input stream closes, and the client should surface the failure - but in practice you check a connection with a read, not with a prescription.

It is not a service that is always up. A hosted assistant with the integration in the middle of the request path is a different arrangement with the trade-offs reversed: less to install, and more of your session outside your control.

It does not make the assistant more accurate. A tool call returns data; the reasoning on top of it is still the model's. MCP does not fix a model that misreads a training load. It makes sure the load was real.

On data: this article makes no claim about how long anything is kept, or about what an assistant does with what it is given. The written-down answer is in the MyNextRow Privacy Policy, and that is the page to read before you point a new assistant at your training data [7] MyNextRow 2026. The protocol has its own floor here: hosts must obtain explicit user consent before exposing user data to a server, and must not pass resource data on elsewhere without consent [1] Specification 2026.

For the connection itself - Claude Desktop, Cursor, the API key, and the things that break on the way - read How to Connect MyNextRow to Claude Desktop and Cursor.

What to do tomorrow

One thing.

Check whether the server can be fetched, then ask it a read. Run npm view @mynextrow/mcp-server version: a version number means the package is there, and a 404 means it is not published yet and nothing you change on your machine will fix it. When it is there, follow How to Connect MyNextRow to Claude Desktop and Cursor until the server is configured, then ask your assistant a question that has a right answer you already know: what your training load is, or how many days in a row you have rowed. Then open the app and check the number against it.

If they match, you now have an assistant that knows your training, and every question you ask it afterwards is grounded in your own rows rather than in a model's memory of what a rower's week usually looks like. If they do not match, you have found the fault while it is still cheap to find, and the connection guide lists the things that cause it.