Vellum

一个能针对文本问题给出确切答案的 MCP 服务器 · 作者：Shuja Jamal

语言模型读的是 token，不是字符。你问它一个段落里有多少个字母，它能做的只是估算，而且常常估算得很离谱。同样，让模型用肉眼对比两个文件，或者不运行正则表达式就预测它会匹配到什么，也是一样的道理。

这些都不是什么难题，它们只是模型没有被设计用来解决的那类问题。所以，模型应该去问。

五个工具

count_text 会以独立的逻辑分别报告可见字符和码点（code point）。因为 café 对用户来说有 4 个字符、 len() 会给出 5 个、而字节数则是 6。你需要哪一种，全靠你为什么会提出这个问题来定，所以它把三种数值都返回。

Related MCP server: text-stats-ai-mcp

使用

Claude Code

claude mcp add --transport http vellum https://vellum-mcp.vercel.app/mcp

或者在本地通过 stdio 运行：

claude mcp add vellum -- python -m vellum.server

**安装别人写的服务器时，有一点我花时间踩过坑：**在会话中途添加的服务器显示为“已连接”，但它的工具在会话重启之前都不可调用。能装完成装得好，和能真正用起来，是两种不同的状态。

Claude Desktop

在 claude_desktop_config.json 中：

{
  "mcpServers": {
    "vellum": {
      "command": "python",
      "args": ["-m", "vellum.server"],
      "cwd": "/path/to/vellum-mcp"
    }
  }
}

运行

pip install -r requirements.txt

python -m vellum.server

这是 stdio，也就是本地客户端所讲的传输方式。至于 HTTP 传输和落地页：

python -m vellum.server --http --port 8000

然后在浏览器打开 http://localhost:8000 即可访问落地页，http://localhost:8000/mcp 则是端点。

测试

python tests/test_vellum.py

总共 46 项检查的事。前半部分直接调用分析函数；后半部分才是核心：它把服务器当作子进程启动，并与它用 MCP 协议交互，完成真正的握手、列出工具、调用工具并把结果读回来。一个函数写得正常的服务器，也仍然可能在协议上都说不出来——只有后半部分这部分能够捕获这样问题。

python tests/test_deploy.py

在部署之前先检查部署形态：重写后的请求能不能以预期路径到达 MCP 应用；?action=demo 能不能进入演示而不是 MCP 应用；静态服务器卡片描述的工具都必须真实存在；整个 bundle 必须是真正有且只有一个独立函数，因为运行时本来就是“一个项目一个函数”。

部署

Vercel，负责托管

vercel

好在这里没有环境变量，没有密钥：每个工具都是它参数的一个纯函数。

这样路由是刻意的，而且值得解释：很明显的那种方案显然行不通。

Vercel 的重写并不保证把浏览器所请求的路径传给你的函数。 将 /(.*) 重写到同一个函数之后，每个每次本来就请求 /api/index 进来，那么一个基于原始路径评论路由的普通应用，就会对任何 URL 均返回它自己的 404——从外部看，这一路简直一点反应都没有。r\u007F. 我之前某个颇尴尬的下午，全部在那件事上了。

而且 Python 运行时只为整个项目构建一个函数，而不会为一个文件一个函数。 我曾在 api/index.py 旁边放着 api/demo.py，在 vercel.json 里已经声明过，也已经打包进部署，但 /api/demo 仍然返回 Vercel 自身的 404。vercel inspect 一眼就出奇清楚 原因：这个 Python lambda 只有一个。可见“文件系统路由”多个 Python 入口的方式并不存在。

所以部署长这样：一个前算子函数，再加上若干静态文件：

/                                  static    public/index.html
/.well-known/mcp/server-card.json  static    generated by build_card.py
/mcp             -> /api/index     function
/api/demo        -> /api/index     function, told apart by ?action=demo

api/index.py 按查询字符串来派发，因为正是重写器在“替换路径”的同时会保留查询字符串这一部分；处理时它把路径放回去，交给 MCP 应用原样路由。为此设计了这两个测试，因为不会有任何你乐得在线上 URL 上才发现的那种情况。

首次写就就能跑对的两个东西，就是 landing page 和 server card（服务器卡片），而它们正好是最不会碰到函数逻辑的两样。

Smithery，用于收录

Smithery 现在的模式是 自带托管（bring your own hosting）：你把一个可流式 HTTP 服务器的公网 HTTPS URL 交给它，它的 gateway 会反代到你那。并没有任何需要去构建的容器。

1. 先在 Vercel 完成部署，并记下完整 URL。

2. 打开 smithery.ai/new

3. 填写 https://你的部署域名.vercel.app/mcp

4. 完成后面的发布流程

然后 Smithery 会把服务器里的工具读取出来，用来生成列表页。文档里写的是“实时扫描”作为正常通路；可当扫描没能完成时，它就会回退到 /.well-known/mcp/server-card.json 这个静态卡片。

可是现实中，Fallback 反而成为了主路径。 发布日志如下：

Server metadata discovered (server card: 5 tools).
Using .well-known/mcp/server-card.json: (5 tools)

所以，这个卡片并不是“当扫描失败才用的保险”，而是真正的机制。设计者 build_card.py 根据服务器自己内置的工具定义去生成它——正因如此，它根本不可能去列出一个不存在的工具。

这份日志还警告没有提供 config schema。这个行为在当前是正确的，是有意为之：因为每个多个工具都纯函数，都拿自己的参数就可以了，所以没有要请用户输入什么数据。但假如有一个接入方 API 且需要传 key 的 server，这个警告就值得重视了。

smithery.yaml把发布流程要填的“资料”记录了下来。请注意，它并不真正驱动一次构建：因为以前的容器化部署这一环已经不再是现在的运作方式了。

两边的套餐也都免费。Vercel 的 Hobby 免费套餐负责托管函数与静态文件；Smithery 的 registry 收录费用则是免费。

整体构造

vellum/
  analysis.py    the actual work, with no MCP anywhere in it
  server.py      the five tools, their descriptions, and the transports
api/
  index.py       the one Vercel function: MCP, and the demo behind a query flag
public/
  index.html     the landing page
  .well-known/mcp/server-card.json   generated
tests/
  test_vellum.py  analysis, then a real MCP handshake over stdio
  test_deploy.py  the routing and the card

analysis.py 没有 import MCP 任何东西。正因如此，测试才能直接调用它；也正是这个原因，落地页上的 demo 能够直接复用与工具函数相同的代码，而不是写出另一套很容易漂移实现的“第二版本”。

给一个模型写工具的注意事项

说明书才是接口。 它说它不是给开发的，而是模型在判断一个工具是否适用时唯一会读的东西。描述含糊，代表这工具永远不会被主动选中；描述错误，代表它会出现在错误的时候。所以 count_text 的描述不是“返回统计信息字典”，而是“当你要的是一个确切的数字时用它，因为读 token 并不等于数字符”。

失败要可读。 broken 的正则会以 {"valid": false, "error": ...} 这种形态返回，而不用抛异常让你直接炸锅；一个函数并不认识某种哈希算法时，它会明确点名有哪些算法可用。模型可以对前一种结果采取行动，对堆栈却不行。

把“模型”真正不能的事挑走。 一个吃 API 的搜索引擎包装成“工具”也是一种诱惑，但“总结这段文字”这种工具不会比模型自己做得更好——它还存在多一次网络请求。而计数、哈希、跑正则，则都是模型的真实短板。只有把这些真实“板”填上，工具才会被人真正用起来，而不是被客气地忽略。

——Shuja Jamal，2026 年 8 月。