最新

我为 Tally 构建了一个 MCP 服务器，它弥合了他们复杂的 API 和简单的自然语言命令之间的差距。 作为一个患有 ADHD 的人，我构建这个是因为在文档、表单构建器和实际工作之间切换上下文会破坏我的工作流程。现在我可以保持在一个对话中，只需描述我需要什么即可。 有趣的的技术挑战： 1. API 复杂性抽象 Tally 的 API 需要深度嵌套的对象来表示简单的字段。一个电子邮件字段需要大约 10 个带有 UUID 的嵌套对象。我构建了一个翻译层，因此用户只需用自然语言说“添加一个电子邮件字段”，服务器就会在幕后处理复杂的结构。 2. 安全的批量操作 对于破坏性操作，我实现了一个预览-确认模式。服务器在预览期间生成一个确认令牌，该令牌必须传回才能执行。这可以防止意外的大规模删除，同时保持对话流程的自然性。 3. 智能速率限制 服务器监控 API 响应并动态调整其行为。当达到速率限制时，它会自动减小批量大小并在请求之间添加延迟。增加了随机化，以防止多个实例同时访问 API。 4. 贯穿始终的类型安全 完整的 TypeScript，并对 MCP 消息和 Tally API 响应进行运行时验证。这在开发过程中发现了几个未记录的 API 缺陷。 性能说明： * 批量创建 100 个表单：大约 12 秒，使用批量操作 * 单独创建 100 个表单：大约 5 分钟，由于速率限制 * 人工创建 100 个表单：可能需要一整周的令人麻木的点击 * 对 10K 响应的提交分析：大约 3 秒 代码已获得 ISC 许可：[https://github.com/learnwithcc/tally-mcp](https://github.com/learnwithcc/tally-mcp) 这尤其有助于当您需要创建多个相似的表单，但您的大脑会抵制重复性任务时。很好奇其他人是否正在构建 MCP 服务器，以及您正在优化哪些工作流程。 也对关于 MCP 与传统 CLI 工具的看法感兴趣。对于简单操作，对话界面较慢，但对于复杂、多步骤的任务（您可能忘记确切的语法）来说，它要好得多。