MCP Foundations: Problem, Mental Model, and Boundaries
Practice this questionLearning objectives
- Understand the integration problem MCP solves.
- Clearly distinguish the host, client, server, model, tool, resource, and prompt.
- Decide when MCP is useful and when a normal API is sufficient.
Why MCP exists
Connecting AI applications to databases, APIs, files, and business services can require building a custom adapter for every integration. MCP provides an open protocol contract through which compatible hosts can discover and invoke server capabilities.
MCP itself is not a model, database, agent, or authorization system. It is a standard integration layer around existing backend capabilities.
Preparing the architecture diagram…
Read the full diagram flow
flowchart LR
U[User] --> H[Host application]
H --> M[Language model]
H <--> C[MCP client]
C <--> S[MCP server]
S --> A[Existing API or service]
S --> D[(Database)]Core roles
- Host: The user-facing AI application. It coordinates the model conversation and permissions.
- Client: The protocol component inside the host. A separate client session may manage each server connection.
- Server: Exposes tools, resources, and prompts.
- Tool: An action or computation, such as
lookup_order. - Resource: Readable context, such as documentation or a record snapshot.
- Prompt: A reusable message template that a user can select.
MCP versus related approaches
| Approach | Main purpose | Relationship with MCP |
|---|---|---|
| REST API | Application-to-application endpoints | An MCP server can reuse an existing REST service. |
| Model function calling | Providing callable schemas to a model | MCP standardizes discovery, transport, lifecycle, and capabilities. |
| RAG | Retrieving relevant knowledge to ground a prompt | MCP resources and tools can expose retrieval services. |
| Plugin | Product-specific extension | MCP provides an open protocol contract. |
When to use it
- When the same tools need to be reused across multiple compatible AI hosts.
- When runtime tool discovery and structured schemas are useful.
- When local tools or remote services need to be exposed through a consistent protocol.
When a normal API may be simpler
- When there is only one fixed backend-to-backend call.
- When an AI host or capability discovery is not needed.
- When the team does not want to operate an additional protocol lifecycle.
Practical checkpoint
There is no need to rewrite an existing GET /orders/:id endpoint. The MCP handler can call the same order service. Authorization must be enforced at the service or handler boundary using authenticated user context; the model's instructions must not be trusted.
Revision note
MCP standardizes context and capability exchange. The host orchestrates execution; the model does not receive direct database access.