HTTP is for humans, MCP is for agents

I’ve been following the evolution of the Model Context Protocol (MCP) with curiosity for a while now, trying to better understand how it fits into the world of AI agents. It’s not new to me, but until recently I struggled to piece everything together in a clear way.

Then I came across this article by glama.ai, which manages to do just that: explain the difference between MCP and APIs clearly, pragmatically, and without too much jargon.

So, MCP vs API: what’s the real difference?

It’s a question I had already asked myself, but now I can talk about it with more substance. This post was born from there: a reinterpretation and adaptation, with the spirit of someone who explores and tries to share what they discover along the way.

MCP: not an API, but a protocol

HTTP APIs (REST, GraphQL…) are flexible – perhaps too flexible. They can have parameters in a thousand places and respond in a thousand formats. Even with OpenAPI, which tries to bring some order, there remains a fundamental problem: every service does things its own way. For humans, this is tolerable – we read the documentation, try things out, make mistakes, and course-correct – but for an AI agent, this variability is a massive obstacle.

MCP (Model Context Protocol) was born precisely from this observation. The idea is simple but powerful: it’s not enough to document existing APIs – you need to define a clear, uniform protocol, designed to be used by LLM agents. MCP is built on JSON-RPC 2.0, an existing and well-supported standard, and introduces a few conventions:

every tool has an input schema and an output schema, strictly JSON;
discovery of available tools happens in real time (tools/list);
communication is bidirectional – the server can ask questions back to the agent;
it can run in local environments, without HTTP, using stdio or WebSocket.

This combination of features makes it predictable for an LLM: it doesn’t have to “guess” how to invoke something – it can simply choose a tool from a list, with parameters already known. It’s a subtle but profound difference: documenting an interface (as OpenAPI does) is different from prescribing it (as MCP does).

API vs MCP: a table to clarify

Concise comparison between traditional APIs and MCP
Aspect	Traditional APIs	MCP
Discovery	static (docs, SDKs)	dynamic (`tools/list`)
Execution	LLM writes HTTP requests	LLM chooses tools, deterministic execution
Communication	client-server	bidirectional (notifications, prompts, interactions)
Human tasks	fragmented across multiple endpoints	encapsulated in a complete tool
Local	always HTTP, CORS, auth	can run locally, via `stdio`

A practical example

Task: find all pull requests on GitHub that mention security and generate a report.

With REST: the agent has to learn to manually paginate through GitHub’s APIs, handle rate limiting, authenticate correctly, interpret the response format (which can change over time), and figure out how to combine multiple calls into a coherent dataset. Any error in parsing or parameters risks breaking the entire chain.
With MCP: the agent has a predefined tool like github.search_issues_and_prs, with a clear and validated input schema. Just pass an object like { query: "security", type: "pr" } and the MCP server handles the call, authentication, rate limiting, pagination, and building the final result. The model receives a structured response, always in MCP format. This way it can focus on the real task: reading, synthesizing, and generating the report.

This separation between “interacting with the world” (handled by the MCP server) and “reasoning and language” (handled by the model) is one of the key points of the MCP approach. And it makes it possible to reuse tools in a modular and reliable way, without requiring the model to reinvent the interface to the outside world every time.

What’s next?

I find the MCP concept fascinating. After all, AI agents are great at making decisions and coordinating, but not at improvising parsing on ambiguous JSON. Giving them a clear protocol, dynamic discovery, and local interaction feels like a step toward truly useful tools.

I also like that MCP doesn’t aim to replace existing APIs, but rather to wrap them with a layer that’s more friendly to agents. It’s a pragmatic choice: building a bridge instead of asking everyone to rebuild the foundations. MCP positions itself as an interpreter, not a revolutionary.

In a way, it reminds me of what happened with GraphQL versus REST: same backend, new way of talking. But with a fundamental difference: while GraphQL is still designed for human developers, MCP is explicitly designed for LLMs and autonomous agents.

This distinction seems crucial to me. It means designing interfaces no longer just for humans sitting at a keyboard, but also for systems that reason in context, learn, and make decisions. A shift in perspective that could open the door to new forms of human-machine collaboration.

I’d like to dig deeper. I’ll try writing small MCP tools for personal use: maybe something that interacts with local files, or extracts data from existing sources. And who knows – maybe even this site could expose its capabilities via MCP, allowing agents to explore it, suggest content, or answer questions from people who – like you – happened to stumble upon this blog post.

Check out the video “What the hell is MCP?” as well.

Let me know what you think!