告诉HN：MCP实施——“可调用”和“友好”之间的差距
最近我一直在与MCP（模型控制点）合作，想分享一些辛苦得来的经验教训，关于什么才是真正让它们有效的因素。
我们构建了一个系统，使得大型语言模型（LLM）能够通过一个流行的企业平台安排会议和预定房间。理论上，我们有自己版本的微软任务矩阵，但在实际操作中，失败率却非常高。
关键在于：让API被LLM“调用”只是简单的第一步。真正的挑战在于让它们“友好”地适应模型的思维方式。可调用性设定了最低标准，而友好性则决定了最高标准（物理世界的API对于模型来说极其难以正确处理）。
像Gitmcp和mcpify.ai这样的工具承诺能够“快速”和“轻松”地将现有系统集成到MCP中。听起来不错，但当你意识到它们并没有提供任何关于实际效果的保证时，就会觉得不那么美好了。
那么，我们如何弥补现实世界API与模型推理之间的差距呢？以下是一些技术方法：
1. **API组合**：将低级API打包成与模型思维相匹配的语义单元
- 例如：对模型而言，安排会议是一个概念，而不是一系列ID查找和日历操作
- 这些是固定的工作流程，不需要代理式推理或复杂的组合
2. **输入处理**：简化参数结构
- 将嵌套结构扁平化为单层表示
- 为参数添加中间计算（例如，将日期字符串转换为时间戳），以支撑模型的推理
3. **输出处理**：优化API响应以提高语义清晰度
- 在每次API调用后明确指定下一步
- 仅提供必要的信息，而不是让模型在噪音中筛选的原始API响应
查看原文
I've been working with MCPs lately and want to share some hard-earned lessons about what actually makes them effective.<p>We built a system where LLMs could schedule meetings and book rooms through a popular enterprise platform. On paper, we had our own version of Microsoft's Task Matrix, but in practice? The failure rate was brutal.<p>Here's the thing: making APIs "callable" by LLMs is just the easy first step. The real challenge is making them "friendly" to how models actually think. Being callable sets the floor; being friendly determines the ceiling (physical-world APIs are incredibly difficult for models to handle correctly).<p>Tools like Gitmcp, and mcpify.ai promise "quick" and "easy" MCP integration of existing systems. Sounds great until you realize they offer zero guarantees about actually working well.<p>So how do we bridge this gap between real-world APIs and model reasoning? Some technical approaches:<p>1. *API Composition*: Bundle low-level APIs into semantic units that match model thinking
- Example: Scheduling a meeting is one concept to a model, not a series of ID lookups and calendar operations
- These are fixed workflows that don't need agent-style reasoning or complex composition<p>2. *Input Processing*: Simplify parameter structures
- Flatten nested structures into single-level representations
- Add intermediate calculations for parameters (e.g., converting date strings to timestamps) to scaffold the model's reasoning<p>3. *Output Processing*: Refine API responses for semantic clarity
- Specify clear next steps after each API call
- Provide only essential information rather than raw API responses that force the model to filter through noise