企业官网建设流程全解析

1. 从 Function Call 到 MCP：为什么你的 AI Agent 总是接不上工具

如果你最近在折腾 AI Agent，大概率遇到过这种场景：想让 Claude 帮你查一下本地数据库里的订单数据，再顺手把结果整理成邮件发出去。你翻遍文档，发现 Function Call 能调函数，但每个模型平台的参数格式都不一样；你换了个模型，之前写好的工具调用代码全部要重写。更麻烦的是，当工具数量从 3 个涨到 30 个，模型开始频繁选错工具，或者干脆编造一个不存在的函数名。

这不是你代码写得不好，而是 Function Call 这套机制本身的天花板。Function Call 的本质是“模型输出一段结构化 JSON，你的代码去解析并执行”。它解决的是“模型能不能调用工具”的问题，但没有解决“工具怎么被统一描述、统一发现、统一授权”的问题。每个平台各自定义 schema，每个开发者各自维护一套胶水代码，生态是碎的。

MCP（Model Context Protocol）就是在这个背景下出现的。它由 Anthropic 主导发布，是一个开放的、通用的协议标准，核心目标是把“AI 模型连接外部数据源和工具”这件事标准化。你可以把它理解成 AI 世界的 USB-C 接口：以前每个设备都有自己的充电口，现在统一成一个标准，谁都能插。MCP 主机（比如 Claude Desktop、Cursor）发起请求，MCP 客户端与 MCP 服务器保持 1:1 连接，MCP 服务器负责暴露工具、资源和提示模板。本地文件、数据库、远程 API 都可以通过 MCP 服务器接入。

这篇文章面向的是想真正跑通 MCP 工具调用链路的开发者。我会先拆解 MCP 与 Function Call、AI Agent 的协作关系，然后给出可复制的 MCP 服务端配置片段和客户端接入参数，最后附一次完整的调用验证步骤。过程中会涉及 Claude 客户端的配置、TaoToken 统一 API 通道的接入方式，以及几个我实际踩过的报错排查。读完之后，你应该能在本地把 MCP 工具调用跑起来，并且理解模型到底是怎么“决定用哪个工具”的。

2. MCP 原理拆解：模型如何选择工具与 Function Call 的本质差异

要理解 MCP，先要理解模型选择工具的机制。很多人以为模型内部有一个“工具路由器”，其实不是。Anthropic 官方给出的解释很直白：当用户提出一个问题时，客户端把问题发送给 LLM，LLM 分析可用的工具并决定使用哪一个，客户端通过 MCP Server 执行所选工具，执行结果被送回给 LLM，LLM 结合结果生成自然语言回复。

关键在第一步：LLM 怎么知道有哪些工具可用？答案是 prompt。MCP 客户端会把所有工具的 name、description、input_schema 格式化成一段文本，塞进 system message 里发给模型。模型基于这段描述和用户问题，输出一个结构化的 JSON 工具调用请求。如果不需要工具，就直接生成自然语言回复。

我截取一段简化后的逻辑，你可以感受一下工具描述是怎么进入 prompt 的：

# 获取所有 MCP Server 暴露的 tools all_tools = [] for server in self.servers: tools = await server.list_tools() all_tools.extend(tools) # 把工具的功能描述格式化成字符串供 LLM 使用 tools_description = "\n".join( [tool.format_for_llm() for tool in all_tools] ) system_message = ( "You are a helpful assistant with access to these tools:\n\n" f"{tools_description}\n" "Choose the appropriate tool based on the user's question. " "If no tool is needed, reply directly.\n\n" "IMPORTANT: When you need to use a tool, you must ONLY respond with " "the exact JSON object format below, nothing else:\n" "{\n" ' "tool": "tool-name",\n' ' "arguments": {\n' ' "argument-name": "value"\n' " }\n" "}\n\n" "After receiving a tool's response:\n" "1. Transform the raw data into a natural, conversational response\n" "2. Keep responses concise but informative\n" "3. Focus on the most relevant information\n" "4. Use appropriate context from the user's question\n" "5. Avoid simply repeating the raw data\n\n" "Please use only the tools that are explicitly defined above." )

这段代码揭示了一个重要事实：MCP 的工具选择机制本质上是 prompt engineering。模型不是通过某种魔法知道工具存在的，而是通过我们提供的结构化描述来理解。这意味着工具的名称、docstring、参数说明写得越清楚，模型选对的概率越高。反过来，如果你把工具描述写成“处理数据”这种模糊表述，模型大概率会选错或者产生幻觉。

那 Function Call 和 MCP 到底差在哪？Function Call 是模型平台提供的一种能力，让模型能输出结构化的函数调用请求。OpenAI、Google、Anthropic 都有自己的 Function Call 实现，但参数格式、调用方式、返回结构各不相同。你为 OpenAI 写的工具调用代码，换到 Claude 上基本要重写。MCP 则是在 Function Call 之上加了一层标准化协议：工具怎么注册、怎么描述、怎么发现、怎么授权、怎么执行，全部有统一规范。模型仍然通过 Function Call 的机制来输出调用请求，但工具的来源和执行链路被 MCP 统一了。

用一句话概括：Function Call 解决“模型能不能调工具”，MCP 解决“工具怎么被标准化地接入和复用”。没有 MCP 的时候，你每接一个工具就要写一套适配代码；有了 MCP，工具提供方按协议暴露能力，客户端按协议发现和调用，开发者不需要重复造轮子。

还有一个容易被忽略的点：MCP 的兼容性不绑定特定模型。因为工具选择依赖的是 prompt 里的工具描述，理论上任何能理解工具描述并输出结构化 JSON 的模型都能配合 MCP 使用。当然，Anthropic 对 Claude 做了专门训练，Claude 在理解工具 prompt 和输出 tool call JSON 方面表现更稳定。这也是为什么很多 MCP 示例默认用 Claude 作为客户端模型。

3. 可复制配置：MCP Server 开发与 Claude 客户端接入参数

这一节直接上可复制的配置。我会用一个最简单的 MCP Server 示例：统计当前桌面上 txt 文件的数量并列出文件名。这个例子足够简单，但完整覆盖了 MCP Server 的开发、调试、接入 Claude Desktop 的全流程。

先准备环境。你需要 Python 3.10+、Claude Desktop、以及 uv 包管理器。uv 是一个用 Rust 写的 Python 包管理工具，速度比 pip 快很多，安装命令如下：

# 安装 uv curl -LsSf https://astral.sh/uv/install.sh | sh # 创建项目目录 uv init txt_counter cd txt_counter # 设置 Python 版本 echo "3.11" > .python-version # 创建虚拟环境并激活 uv venv source .venv/bin/activate # 安装 MCP SDK 和 httpx uv add "mcp[cli]" httpx # 创建 server 文件 touch txt_counter.py

接下来是 MCP Server 的核心代码。这里用 FastMCP 来简化开发，工具的名称和描述直接来自函数名和 docstring：

import os from pathlib import Path from mcp.server.fastmcp import FastMCP # 创建 MCP Server mcp = FastMCP("桌面 TXT 文件统计器") @mcp.tool() def count_desktop_txt_files() -> int: """Count the number of .txt files on the desktop.""" username = os.getenv("USER") or os.getenv("USERNAME") desktop_path = Path(f"/Users/{username}/Desktop") txt_files = list(desktop_path.glob("*.txt")) return len(txt_files) @mcp.tool() def list_desktop_txt_files() -> str: """Get a list of all .txt filenames on the desktop.""" username = os.getenv("USER") or os.getenv("USERNAME") desktop_path = Path(f"/Users/{username}/Desktop") txt_files = list(desktop_path.glob("*.txt")) if not txt_files: return "No .txt files found on desktop." file_list = "\n".join([f"- {file.name}" for file in txt_files]) return f"Found {len(txt_files)} .txt files on desktop:\n{file_list}" if __name__ == "__main__": mcp.run()

注意@mcp.tool()装饰器的作用：它把普通 Python 函数注册成 MCP 工具，函数名成为工具名，docstring 成为工具描述，类型注解成为参数 schema。模型在 prompt 里看到的就是这些信息。所以 docstring 一定要写清楚，这是模型选择工具的唯一依据。

写完 Server 后，先用 MCP Inspector 本地测试：

mcp dev txt_counter.py

终端会输出类似MCP Inspector is up and running at http://localhost:5173的提示。打开这个地址，你能看到所有注册的工具，手动调用count_desktop_txt_files和list_desktop_txt_files，确认返回结果正确。

然后接入 Claude Desktop。打开配置文件：

# MacOS / Linux code ~/Library/Application\ Support/Claude/claude_desktop_config.json

在配置文件里加入以下内容，路径替换成你的实际路径：

{ "mcpServers": { "txt_counter": { "command": "/opt/homebrew/bin/uv", "args": [ "--directory", "/Users/yourname/mcp/txt_counter", "run", "txt_counter.py" ] } } }

这里有几个关键点。command建议用 uv 的绝对路径，通过which uv获取。--directory指向项目目录，run后面跟 server 文件名。配置保存后重启 Claude Desktop，如果配置正确，你会在输入框附近看到 MCP 工具的图标。

如果你用的是 Cline、Cursor 或其他支持 MCP 的客户端，配置结构类似，但字段名可能不同。以 Cline 的 MCP 配置为例，通常需要提供 Base URL、API Key 和 Model ID 三件套。如果你希望通过统一 API 通道接入 Claude 模型，可以在 TaoToken 的 console 里创建 API Key，然后在客户端配置里填入：

{ "baseUrl": "https://taotoken.net/api", "apiKey": "你的_API_Key", "model": "claude-sonnet-4-20250514" }

Base URL 填https://taotoken.net/api，不要加 UTM 参数。API Key 在 console 页面生成，Model ID 根据你实际使用的 Claude 版本填写。这样配置之后，客户端会通过统一通道调用 Claude，同时 MCP Server 仍然在本地运行，工具执行结果不会离开你的设备。

4. 完整调用验证：从用户提问到工具执行结果回传

配置完成后，来跑一次完整的调用验证。打开 Claude Desktop，输入以下 prompt：

能推测我当前桌面上 txt 文件名的含义吗？

这个问题的设计意图是：它没有直接说“调用工具”，而是让模型自己判断需要先获取文件名列表。如果 MCP 接入正常，Claude 会先请求调用list_desktop_txt_files工具。你会看到界面上弹出权限请求，点击 “Allow for This Chat”。

工具执行后，结果会回传给模型。模型拿到文件名列表，再结合文件名推测含义，生成自然语言回复。整个过程你不需要手动指定工具，模型根据工具描述和用户问题自主选择。

如果你想更直观地验证工具调用链路，可以换一个更明确的 prompt：

我桌面上有多少个 txt 文件？分别叫什么名字？

这次模型应该会依次调用count_desktop_txt_files和list_desktop_txt_files，然后把两个结果合并成一段回复。你可以在 Claude Desktop 的对话详情里看到工具调用的中间过程，包括模型输出的 JSON 调用请求和工具返回的原始结果。

从技术链路上看，这次验证覆盖了以下环节：Claude Desktop 作为 MCP Host 发起请求，MCP Client 与本地 MCP Server 建立连接，Server 暴露的工具描述被格式化进 system prompt，Claude 模型输出结构化 tool call JSON，Client 解析 JSON 并执行对应 Python 函数，执行结果回传给模型，模型生成最终自然语言回复。

如果你在验证过程中遇到工具没有被调用的情况，先检查 Claude Desktop 的日志。MacOS 下的日志路径通常在~/Library/Logs/Claude/目录下。常见原因包括：配置文件 JSON 格式错误、uv 路径不对、Python 环境缺少依赖、或者工具描述不够清晰导致模型没有识别出需要调用工具。

还有一个细节值得注意：MCP 工具的执行结果会作为 system message 重新发送给模型。这意味着如果工具返回的数据量很大，会占用上下文窗口。在实际开发中，建议工具返回精简的结构化数据，而不是把整个数据库查询结果原样丢给模型。模型需要的是“足够生成回答的信息”，不是“全部原始数据”。

5. 常见报错排查：401、local proxy failed、reading choices 与 OAuth 问题

这一节整理几个我在接入 MCP 和统一 API 通道时实际遇到的报错，以及对应的排查思路。

401 Unauthorized：这个报错通常出现在客户端调用模型 API 时。如果你用的是 TaoToken 统一通道，先检查 API Key 是否在 console 里正确生成，以及是否复制完整。Base URL 应该是https://taotoken.net/api，不要多加斜杠或路径。如果 Key 没问题但仍然 401，检查请求头里的 Authorization 字段格式，通常是Bearer sk-xxx。另外注意 Key 是否有额度或权限限制。

local proxy failed / connection refused：这个报错说明客户端无法连接到 MCP Server。先确认 MCP Server 进程是否在运行。如果你是用mcp dev启动的，检查终端是否还在前台运行。如果是通过 Claude Desktop 配置启动的，检查配置文件里的command路径是否正确。uv 的绝对路径可以用which uv获取，常见路径是/opt/homebrew/bin/uv或/usr/local/bin/uv。另外，--directory参数指向的目录必须存在，且run后面的文件名要与实际文件一致。

reading choices / unexpected end of JSON input：这个报错通常出现在模型返回的 tool call JSON 格式不完整时。可能的原因包括：模型输出被截断、工具描述太长导致上下文超限、或者模型产生了幻觉输出了非法 JSON。排查方法是先简化工具描述，减少同时注册的工具数量，然后逐步增加。如果问题持续，检查客户端的 max_tokens 设置是否太小，导致模型输出被截断。

OAuth 相关报错：部分 MCP Server 需要 OAuth 授权才能访问远程资源。如果你在接入这类 Server 时遇到 OAuth 报错，先确认回调地址是否配置正确，以及授权范围是否包含所需权限。对于本地开发，可以先用不需要 OAuth 的工具做验证，确认基础链路通畅后再接入需要授权的服务。

工具被调用但返回结果为空：检查工具函数的返回值类型是否与声明一致。MCP SDK 会根据类型注解做序列化，如果返回了不符合声明的类型，可能导致结果丢失。另外，如果工具函数抛出了未捕获的异常，MCP Server 会返回错误信息而不是正常结果，模型收到错误后可能不会正确展示。

Claude Desktop 重启后 MCP 工具消失：这是配置文件没有生效的典型表现。检查 JSON 格式是否合法，可以用python -m json.tool验证。另外，Claude Desktop 对配置文件的路径敏感，MacOS 下必须是~/Library/Application Support/Claude/claude_desktop_config.json，注意空格需要转义。

如果你在排查过程中需要重新生成 API Key 或查看调用日志，可以访问 TaoToken 的 console 页面。接入文档里有各客户端的详细配置示例，包括 Claude Code、Cline、Cursor 等。对于长期编码和 Agent 场景，可以考虑 Coding Plan，减少频繁配置的麻烦。

6. 把 MCP 用起来：从本地工具到统一 API 通道的实践建议

跑通第一个 MCP Server 之后，你可能会想：接下来怎么把它用到实际项目里？我的建议是从小工具开始，逐步扩展。

先把你日常重复操作最多的那件事做成 MCP 工具。比如每天要查的数据库表、要读的日志文件、要调的内部 API。每个工具只做一件事，docstring 写清楚输入输出。工具数量控制在 10 个以内，模型选择准确率会比较高。超过 10 个之后，考虑按领域拆分多个 MCP Server，让客户端按需加载。

工具描述的质量直接决定模型调用准确率。我试过把query_order的 docstring 写成“查询订单”，模型经常在用户问“最近有什么异常订单”时选错工具。后来改成“根据订单号查询订单详情，返回订单状态、金额、创建时间；不适用于按条件筛选订单列表”，准确率明显提升。docstring 里要写清楚：这个工具做什么、输入参数是什么、什么情况下不该用。

对于需要调用远程模型的场景，统一 API 通道能省掉很多切换成本。你不需要为每个模型平台维护一套 API Key 和 Base URL，客户端配置里填一次就行。MCP Server 仍然在本地运行，工具执行结果不离开你的设备，模型只负责决策和生成回复。这种本地执行加远程推理的组合，在安全性和灵活性之间取得了不错的平衡。

最后提醒一点：MCP 还处于快速发展阶段，协议细节和 SDK 接口可能会有变化。建议定期查看官方文档和 SDK 的 release notes。如果你在接入过程中遇到问题，优先检查工具描述和配置文件，这两个地方出错的概率最高。把第一个工具跑通之后，后面的扩展就是复制粘贴加改 docstring 的事。