模型存在三类能力边界。工具调用为其接入外部程序，MCP 规定这段接入如何实现。本页从能力边界讲起，依次说清为什么需要一个协议、MCP 处在协议栈的哪一层、它与相近做法如何区分，最后落到本课的任务。
语言模型擅长生成自然语言，但有三类任务无法独立完成。工具调用正是为这三类任务准备的。
训练语料截止之后发生的事，模型无从得知。问它「最新版本」「今天」，它只能按概率续写，且常给出高置信度的错误答案，即幻觉（hallucination）。
精确计算、单位换算、日期推算：自回归（autoregressive）逐词生成的数字并不可靠——它是在续写最可能的下一个词，并非在执行计算。这类任务应交由确定性的程序完成。
数据库、文件系统、业务接口、网页：模型的输出止于文本，既读不到外部状态，也无法改变外部状态。
模型只负责三件事——判断是否需要调用、决定调用哪一个、把结果组织为自然语言。这就是工具调用（tool use / function calling，函数调用：让模型以结构化形式说出「我要调哪个函数、参数是什么」，由外部程序真的去调）。
没有协议时，每个应用 × 每个工具源都要单独编写一套适配。
三个应用接三个工具源，需要编写九套适配；再增加一个工具源，每个应用都要随之修改。工作量是两侧数量的乘积 O(M×N)。
统一协议之后，工具源只实现一次服务器端、应用只实现一次客户端，工作量降为两侧数量之和 O(M+N)。新增一侧，改动不再随另一侧增长。
同一问题此前已有两次先例：语言服务器协议（LSP，Language Server Protocol）解决「编辑器 × 编程语言」，开放数据库互连与 Java 数据库连接（ODBC / JDBC）解决「应用 × 数据库」。MCP 是这一问题在「应用 × 工具」上的答案。
MCP 是一份开放规范：规定宿主应用与工具服务器之间，用什么方法名、按什么报文体交换「有哪些工具」和「调用某个工具」。
全称里的「模型上下文」说的是目的——为模型准备上下文；真正通信的两端都是程序：一边是宿主应用（host，承载对话的那支程序），一边是工具服务器（server，提供工具的那支程序）。模型不发报文，也不知道服务器地址与令牌。
能力层：服务器能暴露什么；传输层：报文靠什么传输；报文层：报文是什么形状——用的是 JSON-RPC 2.0（一种轻量的远程调用报文格式）。换掉其中一层，另外两层不必改动。
MCP 管的是「工具从哪来、怎么接上去」；「本次是否应当调用、调用哪一个」归模型判断，「到底能不能执行」归宿主裁定。三者各管一段，不应指望协议替你做决策。
工具接入这件事上有若干现成做法，容易混淆。按「各管一段」来区分就不会乱。
| 做法 | 管的是哪一段 | 与 MCP 的关系 |
|---|---|---|
| 函数调用（function calling / tool use） | 模型侧接口：模型用结构化形式表达「要调哪个、参数是什么」 | 互补而非替代：它决定模型怎么开口要工具，MCP 决定工具从哪来 |
| 厂商私有的插件或工具格式 | 单个厂商生态内的工具接入 | 换一家厂商就要重写一遍；MCP 换来的正是免掉这份重写 |
| OpenAPI（接口描述规范）+ 函数定义 | 把已有的 HTTP 接口描述成工具 | 接入成本低，能复用存量接口；但只有「调用」，缺少统一的发现过程与资源、提示等能力 |
| 智能体框架自带的工具抽象 | 框架内部的工具注册与调度 | 与协议正交：框架之内照样可以去连一台 MCP 服务器 |
六个知识点不是一张并列清单，它们分落在一次调用的两端——工具怎么被接上来，以及接上来以后要补什么。
一端是服务器：它须正确实现协议——初始化握手、列出工具、执行工具，并对令牌做校验。协议分层与工具声明主要落在这一端，实现者决定模型能看到哪些工具、每个工具的参数结构如何。
另一端是宿主里的编排：它须正确实现循环——把工具声明交给模型、解析模型提出的调用、按结构校验后执行、把结果作为工具消息回传、控制轮次与累计次数。调用循环、信任边界、可观测性落在这一端，实现者决定哪些动作真的能发生。