Blog · AI · 5 min read · Updated August 2026

What Is MCP, and Why Should a Lifter Care?

You've probably seen "MCP" mentioned around AI tools without anyone explaining it. It's simpler than it sounds, and for anyone who tracks their training it's the difference between an AI that guesses about you and one that knows.

The one-sentence version

MCP — the Model Context Protocol — is a standard way for an AI assistant to plug into another app and use it. That's it. It's the reason you can add a "connector" in ChatGPT or Claude and suddenly have it reading from a service it knew nothing about five minutes ago.

Why a standard was needed at all

An AI model on its own is a closed box. It knows what it was trained on, plus whatever you type into the chat. It cannot see your calendar, your email, or your training log — not because it's forbidden, but because there's no wire connecting them.

Before MCP, every one of those wires had to be built by hand: a custom integration between one AI product and one service, repeated for every combination. That scales badly, which is why for years your AI assistant could talk about anything and actually do almost nothing.

MCP replaces the tangle with one shared shape. A service describes itself once — here are the things you can ask me for, here's what each one needs — and any AI assistant that speaks the protocol can pick it up. It's the difference between every appliance needing a proprietary plug and everyone agreeing on an outlet.

What that means for your training data

Concretely: your workout app can expose your training history as something an AI can look up mid-conversation. That flips the usual dynamic.

Without a connection, you ask "is my bench progressing?" and the model answers from general principles, because that's all it has. With one, it fetches your actual bench sets from the last few months first, then answers about those numbers. Same model, completely different conversation.

The second thing MCP allows is actions, not just reads. A service can expose "create a workout" the same way it exposes "list my sessions." So the assistant that just told you your bench has stalled can build next week's session around fixing it — and you never leave the chat.

What it doesn't mean

A few things worth being clear on, because "AI can now access your data" is the kind of sentence that deserves scrutiny:

Nothing connects itself. A connector exists because you added it and signed in. Your apps are not quietly becoming visible to AI assistants in the background.

The service decides what's exposed. MCP doesn't hand an assistant a key to the whole database — it offers a specific, deliberately chosen list of things. If a workout app doesn't expose deletion, no amount of clever prompting will delete your training history, because the capability isn't there to invoke.

Permissions are still yours. A well-built connection lets you choose read-only versus read-and-write, and revoke it whenever you want.

It doesn't make the model smarter. It makes it informed. A model with bad reasoning and good data still gives you bad advice — it's just now specific bad advice. Grounding is necessary, not sufficient.

Should you bother?

If you don't log your training, no — there's nothing on the other end of the wire, and a connector to an empty log is worse than nothing because it produces confident answers from three data points.

If you do log consistently, the case is strong, and it comes down to context. Your training doesn't happen in a vacuum. The AI you already talk to knows about the trip you're taking, the race you signed up for, the week from hell at work. Your training app knows your numbers. Neither one alone can answer "given everything, what should I do this week?" — and connected, they can.

That's the real argument for caring about MCP as a lifter. Not the protocol. The fact that your data stops being trapped in one app.