LESSON 01 / 18·2 min readFoundation

MCP Foundations: Problem, Mental Model, and Boundaries

Must knowConcept lesson
01 Understand02 Recall03 Prepare

Learning 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.

Architecture at a glanceFollow the arrows to see how the parts connect.

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.
ApproachMain purposeRelationship with MCP
REST APIApplication-to-application endpointsAn MCP server can reuse an existing REST service.
Model function callingProviding callable schemas to a modelMCP standardizes discovery, transport, lifecycle, and capabilities.
RAGRetrieving relevant knowledge to ground a promptMCP resources and tools can expose retrieval services.
PluginProduct-specific extensionMCP 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.

PAUSE & RECALL

Can you explain it without the notes?

MCP Foundations: Problem, Mental Model, and Boundaries

Use your own words. Explain an example and one limitation before checking the explanation.

Check your explanation

Learning objectives

CONNECT IT TO YOUR INTERVIEW

Turn this concept into a clear answer.

Practice this concept
YOUR NEXT STEP

Keep connecting the ideas.

Next lesson: End-to-End Request Flow and Trust Boundaries

Adapted from 20_MCP_SERVER.md · “1. MCP Foundations: Problem, Mental Model, and Boundaries”. Examples are study fragments; framework behavior can depend on your version.