What MCP solves

Model Context Protocol, or MCP, is a standard way for an AI application to discover and use capabilities exposed by another program.

Without a shared protocol, every application needs a custom integration for every data source or action. MCP gives both sides a common vocabulary for discovery, input schemas, calls, results, and errors.

Think of it as a boundary between two programs:

flowchart LR
  accTitle: MCP integration boundary
  accDescr: An AI host uses an MCP client to call an MCP server, which reaches a narrowly scoped file system, database, or API with its own credentials.
  Host["AI host"] --> Client["MCP client"]
  Client -->|"Tools, resources, prompts"| Server["MCP server"]
  Server --> Files
  Server --> Database
  Server --> API

The host can connect to a new server without learning that server’s private implementation. The server can expose the same capability to more than one compatible host. This reduces integration work, but only when the capability has a clear contract.

MCP does not make an integration trustworthy by itself. A server is still software with access to data and systems. You must understand what it can do and give it only the access it needs.

It also does not replace the underlying API, database driver, or permission system. A GitHub server may still call GitHub’s API. MCP describes how the host discovers and invokes the server-facing operation.

Start from a user task, not from “connect everything.” A useful project-notes server might expose search and read operations over one folder. It does not need a general shell command or access to the whole disk.

In this course we will first connect one existing server. Then we will build a small project-notes server with two read-only tools, one resource, and one prompt.

Draw one integration you use today. Mark the host, server, underlying system, credentials, and point where a human approves an action. If those boundaries are unclear, the integration is not ready to trust.