Things 官方：Third-Party AI Tools and Things
Things 3 是我很喜欢的一类任务管理工具：界面干净，数据结构清楚，也没有为了追赶 AI 热潮，急着往里面塞一个聊天机器人。
但没有官方 AI 接口，并不代表大家没有需求。
GitHub 上的 hald/things-mcp，就是一个第三方 Things MCP Server。接入以后，可以让 Claude Desktop、Claude Code、Codex 等支持 MCP 的 Agent 读取 Things 任务、分析项目、整理优先级，也可以创建和修改待办。
例如直接问：
- 今天有哪些事情需要处理？
- 帮我按照四象限分析现有任务。
- 找出 Anytime 中超过两周没有更新的任务。
- 根据下周的会议，新建几个准备事项。
体验上当然很诱人。但这类工具有一个必须先说清楚的问题：它不是 Things 官方服务，安全性和数据边界需要用户自己判断。
things-mcp 能做什么
这个项目提供的工具比较完整。
读取方面，它可以访问 Inbox、Today、Upcoming、Anytime、Someday、Logbook 和 Trash，也能读取项目、区域、标签、标题、清单和最近创建的任务。
写入方面，它可以：
- 新建待办、项目和区域；
- 修改任务标题、备注、日期、截止时间和标签；
- 批量更新多个待办；
- 修改清单项目；
- 移动任务、完成任务或取消任务。
项目采用 MIT 许可证，支持通过 uvx things-mcp 启动，也可以安装成 Claude Desktop 的 MCPB 插件。默认使用本地 stdio 通信，同时提供可选的 HTTP 传输。
写稿时，仓库约有五百多个 Star，仍在持续更新。
它对 Things 数据的访问方式是什么
看安全性，不能只看 README 写着“本地运行”，还要看它到底怎样连接 Things。
things-mcp 主要组合了三种方式。
第一种是 Things URL Scheme。创建和修改待办、项目时，它会构造 things:///add、things:///update 等链接交给 Things 执行。这是官方列出的安全方式。
第二种是 AppleScript。由于 URL Scheme 不支持部分区域操作，项目使用 AppleScript 新建或修改 Area。这同样在 Things 官方列出的安全方式之内。
第三种是 things.py。列表、搜索和详情读取主要依赖 things-py。这个 Python 库会直接读取 Things 保存数据的 SQLite 数据库，再通过 SQL 查询整理任务、项目和标签。
从目前代码看，things-mcp 的常规写入没有直接修改 SQLite，而是交给 URL Scheme 或 AppleScript。直接读取数据库通常也比直接写入风险低。
但问题在于，Things 官方并没有把“直接读取数据库”列为受支持的安全连接方式。官方的原话很明确：安全方式包括 URL Scheme、Apple Shortcuts、AppleScript 和 Mail to Things；不在清单中的方式，都不能视为官方支持的安全方案。
因此，不能简单地把 things-mcp 归类为“肯定危险”，也不能因为它开源、在本机运行，就说它“完全安全”。更准确的判断是：
它的写入路径大部分采用官方认可的方法，但读取路径依赖直接访问 Things 数据库，属于第三方、非官方支持的实现。
官方真正担心的是什么
Cultured Code 在官方支持页面中特别提醒了两个风险。
第一，不要使用直接写入 Things 数据库的工具。这可能破坏数据库，导致崩溃或数据丢失。官方表示，这不是理论风险，已经有用户因为第三方工具绕过安全接口而丢失数据。
第二，任何要求提供 Things Cloud 账号或密码的工具都不安全。Things Cloud 凭据绝不能交给第三方服务。
things-mcp 当前的安装说明没有要求 Things Cloud 账号密码，这是好事。但它需要读取本地 Things 数据，并可能读取 URL Scheme 的授权令牌，用于修改和批量更新任务。
一旦接入 MCP，风险就不只是“这个 Python 程序会不会写坏数据库”，还包括“Agent 会不会调用错工具”。例如，一句含糊的“帮我整理这些任务”，可能被理解为批量修改、移动甚至完成任务。
还有一层容易被忽略的隐私问题
MCP Server 在本机运行，不代表任务内容只留在本机。
当 Claude、Codex 或其他 Agent 调用 get-today、search-todos 时，MCP 会把任务标题、备注、标签、截止时间和清单内容返回给 Agent。随后，这些数据是否离开电脑，取决于你使用的模型和服务商。
如果 Agent 使用云端模型，Things 中的任务内容可能作为对话上下文发送给第三方模型提供商。工作项目名称、客户信息、私人计划和医疗事项，都可能包含在其中。
这正是 Things 官方要求用户查看第三方 AI 服务隐私政策的原因。数据库没有上传，不代表数据库里的内容没有上传。
如果确实想试，至少做好这些防护
我不会建议完全没有技术判断能力的用户，直接把 Things 全部权限交给第三方 MCP。
如果确实有需求，可以先做几层防护：
- 先备份 Things。测试任何具备写入能力的第三方工具之前，确认本地备份能够恢复。
- 优先使用 stdio。让 MCP 只作为当前 Agent 启动的本地子进程，不要为了方便把 HTTP 服务监听到
0.0.0.0。 - 固定版本。不要每次都无条件拉取最新包，可以先审查并固定一个明确版本，例如使用带版本号的 uvx 包。
- 先测试读取。从 Inbox、Today 等只读查询开始，不要一上来测试批量更新。
- 限制工具权限。如果 MCP 客户端支持工具白名单，先只开放读取工具，把
bulk-update-todos等写操作关闭。 - 不要提供 Things Cloud 凭据。任何要求账号密码的连接方案都应该立即停止。
- 检查模型的数据政策。任务中有工作秘密或隐私内容时，不要把完整数据库交给不明确的云端模型。
- 关键修改必须确认。批量移动、完成、取消或覆盖清单前，让 Agent先列出拟修改内容，再由人确认。
方便，不代表值得无条件接入
Things 接入 MCP 后确实很有想象力。
AI 可以做每周复盘、识别长期没有推进的项目、把会议和任务联动起来，也能根据自然语言快速创建结构化清单。对重度 Things 用户来说，这些能力很有吸引力。
但任务管理数据比很多人想象得敏感。它不只是“买牛奶”和“交水费”，还可能包含客户、工作安排、家庭计划、健康状况和未来决策。
things-mcp 是一个开源的第三方项目，不是 Cultured Code 官方集成。它的代码可以审查，写入方式总体比较克制，但读取数据库的方式不在官方安全方法清单中，MCP 把任务内容交给 AI 后也存在额外的隐私风险。
所以我的态度是：可以研究，可以在备份和最小权限下试用，但不要因为它“本地运行”“开源”或者“有几百个 Star”，就跳过最基本的安全判断。
Things 官方的建议很值得记住：
第三方 AI 连接方式质量和安全性差异很大。在使用前，确认它只依赖官方列出的安全方法，并理解任务数据会如何被第三方 AI 服务处理。
