MCP vs API

How the Model Context Protocol works — and how it differs from a traditional API

1The traditional API

Your codeYou decide what to call, when, with what args

→HTTP

api.example.comFixed endpoints:
GET /v1/users
POST /v1/orders

→JSON

Your codeParses the fixed response shape you coded against

Every integration is bespoke: you read the docs, hand-write a client for that service's endpoints, and update it whenever the API changes. One service = one custom integration.

2The MCP way

AI HostClaude Desktop, Codex, Muse…
runs the model

→embeds

MCP ClientOne per server.
Speaks the protocol.

JSON-RPC 2.0 over stdio (local) or HTTP + SSE (remote) — two-way, stateful

↕

MCP ServerAdvertises what it can do:
Tools · Resources · Prompts

Discovery. Client connects; server answers tools/list with every tool's name, description, and input schema. No docs to read — the server describes itself.

Decision. The model reads those descriptions and decides which tool to call, with what arguments — at runtime, per conversation.

Execution. Client sends tools/call; the server runs it (search a corpus, query a DB, hit an API) and returns the result.

Answer. The model folds the result into its reply to you.

One protocol, unlimited servers. Write the server once; every MCP-compatible host can use it with zero per-client integration code.

The key insight: with an API, you write the integration — you decide every call in code, ahead of time. With MCP, you describe capabilities and the model writes the integration at runtime, choosing tools the way a developer would. The intelligence moves from your code into the conversation.

3Side-by-side

	Traditional API	MCP
Who decides what to call	You, in code, ahead of time	The model, per conversation, from tool descriptions
Discovery	Read the docs, hand-write a client	`tools/list` — the server describes itself
Integration cost	Bespoke per service	One protocol; any host works with any server
Transport	Usually HTTP REST	JSON-RPC 2.0 over stdio or HTTP+SSE
Primitives	Endpoints with fixed shapes	Tools (actions), Resources (data), Prompts (templates)
Data access	Remote service, API keys	Often local — the server runs next to your data
Changes	Client code breaks, you patch it	Server updates its descriptions; model adapts

4Your Luke OS MCP, mapped

Codex / Claude Desktopthe host

→

MCP clienttools/list → sees 4 tools

↕

server.pyyour MCP server

→

data.jsonthe Luke OS corpus

You ask "what needs my eyes?" → the model sees the tracking tool description → calls tracking(status="needs-eyes") → server.py reads data.json → the model summarizes the result. No endpoint was hard-coded for that question — the model composed it from the tool's description.

v2026.10.02-19.20