Not much feels different. And that’s exactly why it confuses people. They expect magic.
I want a list of users. Here’s my pseudo-code way of sorting it out ways of doing it.
Traditional-coder scenario
Human: “I want user data from your system.”
Human goes to the docs
Finds the right endpoint
Sets up auth
Writes code: GET /users
Parses the response and uses it
The human is doing discovery, auth, integration, and parsing.
AI without MCP
Human Prompts: “List users from System X, using this doc [url]”
AI tries to reverse engineer endpoints and payloads
Maybe works, Maybe hallucinates
Human does not get coffee, they have to watch the AI progress and steer it.
The AI is the one reading the docs, but the developer is still doing work.
MCP scenario
Human: “List all users from in a Modal”
That’s it. Human goes to get coffee.
AI checks connected MCP servers
AI asks: “Do I have a tool for this?”
Finds a structured tool like list_users exposed by that service’s MCP server
That tool defines:
- What it does
- What inputs it needs
- How auth works (handled server-side)
AI calls the tool through the MCP client
MCP server executes the call safely
Structured user data comes back
AI keeps going with real data
AI: “Modal with Users is ready for your review”
Human Browsing Web
Human says, “I want to get Users for the [service]”
Human opens Chrome and goes to https://%5Bservice%5D.com
Human click “Users” on the page.
They read list of Users on the page and spams them (or whatever else humans like to do these days.)
You don’t manually open a socket and craft packets. Your browser speaks a standard protocol and every website that follows it “just works.”
MCP is trying to be that layer, but for AI using software tools instead of humans using web pages. The key part is the contract. The AI is not inventing how to call your system. It is using a capability your system formally exposed over a shared protocol.
Sean Shadmand 