我的计算器网站变身 MCP Server：让 AI 调用真实工具

我的计算器网站变身 MCP Server：让 AI 调用真实工具 | 前端进阶之旅

Full translation

完整中文译文

让语言模型计算 2 + 3 * sqrt(16)，它通常能得到正确答案。问它 1,000,000 秒等于多少天，或者 30 年的复利计算，它会充满信心地回答——但有时会悄悄出错。它是在预测下一个 token，而不是在运行计算器。

我本身已经有一个计算器了。一整个网站的计算器——过去一年里我陆陆续续做的七十多个转换器和计算器。所以我没有写另一个聊天机器人包装器，而是做了显而易见的事：让 AI 通过 MCP 直接调用真实的工具。

以下是整个过程，包括那些没有work的部分。

什么是 MCP

Model Context Protocol（MCP）是一种标准方式，让 AI 助手能够发现并调用外部工具。助手向你的服务器发送"你能做什么？"，得到一个带类型的工具列表，然后用参数调用它们——你运行实际的代码并返回真实结果。Claude 支持它，越来越多的客户端也在支持。可以把它想象成给模型一双手，而不是让它记住所有东西。

约束一切的设计决策

我的网站是静态的，由一个 Cloudflare Worker 提供服务。没有后端可以启动，没有容器，没有数据库。所以 MCP 服务器不能是一个独立服务——它必须存活在我已经部署的这个 Worker 里面。

这促使我采用最简单可行的设计：基于普通 HTTP 的 JSON-RPC 2.0，完全无状态。无会话、无认证、无存储。POST 是工具调用，GET 返回服务器信息。整个实现只有几百行代码，零依赖，与网站按钮已经在运行的计算代码共享。

POST /mcp
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "scientific_calculator",
              "arguments": { "expression": "2 + 3 * sqrt(16)" } } }

{ "jsonrpc": "2.0", "id": 1, "result": {
    "expression": "2 + 3 * sqrt(16)", "result": 14 } }

决策一：每个结果都链接回一个真实页面

我最在意的一个设计选择：每个工具响应都包含一个 source_url，指向该工具的人类可读页面。

{ "expression": "2 + 3 * sqrt(16)", "result": 14,
  "provider": "SmartTools",
  "source_url": "https://smart-tools.xyz/en/scientific-calculator" }

两个原因。诚实的原因：如果助手告诉用户"你的月供是 X"，用户应该能够点击进去看到公式，而不是对一个黑箱盲目信任。自私的原因：这是一条回到网站的引用链。（链接甚至会自动本地化——传入 locale: "de" 就会得到德语页面。）

决策二：永远不用 eval

科学计算器可以计算任意表达式——sin(pi/6)、5!、log(1000)、嵌套括号、运算符优先级。偷懒的方式是用 eval()。但这段代码运行在服务于整个网站的同一个 Worker 里面，我不会打开那扇门。

所以我写了一个手动的递归下降解析器。无聊、安全，而且迫使我把语法决策显式化。其中一个容易让人踩坑的决定：

-2^2   // -4，而不是 4

一元负号的优先级比指数运算更低，所以这等价于 -(2^2)——这是数学惯例，也是 TI 计算器给出的答案。阶乘的优先级比 ^ 更高；% 是向下取整的模运算，而不是"百分号"。这些都不是运行时猜的，全部写在解析器里。

解析器在网站组件和 MCP 工具之间是完全字节级一致的，测试确保它们永远不会产生偏差。

我无法暴露的东西（诚实的上限）

并非所有功能都开放了。网站有图像转换器、PDF 转图片工具、Excel 查看器——它们都无法成为 MCP 工具。它们依赖运行在用户本机上的浏览器 canvas 和 WASM；在无状态的 Worker 里没有东西可以运行。大约十个工具保留为仅浏览器端。任何纯计算或文本处理的工具都通过了筛选——目前共 73 个。

我宁愿直说，也不愿假装服务器能做它实际做不到的事。

无需 API key、无需注册、不存储任何东西——它读取你的输入、计算、返回结果。

claude mcp add --transport http smart-tools https://smart-tools.xyz/mcp

或者直接指向任何 MCP 客户端的端点：

{ "mcpServers": {
    "smart-tools": { "type": "http", "url": "https://smart-tools.xyz/mcp" } } }

更完整的说明（以及工具列表）见 smart-tools.xyz/en/mcp。

我仍然想弄清楚的事

我一直反复思考的问题是：一个通用计算工具对一个现代模型究竟有多大帮助，还是说干脆让它自己推理就够了。对于算术，它现在显然推理得很好。对于长单位转换、金融公式，以及任何需要绝对精确的地方，给它一个确定性工具仍然比信任一个 token 预测器更安全。如果你对此有proper的测量，我真心想听听。

这是一个副项目，它是免费的，我做它是因为 alternatives 就是信任 LLM 的心算能力。如果你试了发现有问题，告诉我——这正是做一个展示工作过程的工具的意义所在。