Xberg API 服务器与 MCP 协议集成
为 AI 代理提供文档提取的 REST API 和 MCP 服务器，无缝集成到 Claude 等代理中。
证据显示有安全文档（SECURITY.md）列出了针对恶意文档输入的具体缓解措施（解压炸弹、路径遍历等），且默认配置为保守（如最大压缩率、超时），这表明了安全意识和基本的数据流透明度。但技能文档本身未描述权限要求或用户确认机制，且 CorsLayer 默认是 permissive 的（依赖环境变量收紧）。发布者未经验证，无法确认版本归属。因此信任分被限制在中等，因为权限和确认细节缺失导致降分。
技能文档详细描述了 REST 和 MCP 架构，包括错误处理（如 ApiError 映射到 HTTP 状态码）和超时设置，这有助于可靠性。然而，静态审查无法运行任何关键路径，且没有内嵌的测试套件专门覆盖该技能本身，只有 e2e 测试文件（batch 和 code）未直接关联到技能定义。因此，可靠性被限制在中等偏低，因为关键路径未被本静态审查实际验证。
技能文档清晰地定义了目标用例（REST API 和 MCP 集成），提供了详尽的端点、参数和配置信息，这些有助于精确触发。但它没有明确声明非适用边界或环境限制（例如，对资源密集型文档的适用性）。作为 FollowSkills 服务的中国用户，核心功能依赖于本地部署，不依赖被屏蔽的外部服务，这是积极因素。然而，缺乏边界证据将分数限制在中等偏低。
技能文档结构良好，提供了位置、配置和示例，并且仓库有 MIT 许可证和明确的责任归属（作者在 Cargo.toml 中列出）。但技能文档未包含版本历史或变更日志，也未明确说明维护责任和更新路径，尽管存在安全文档。这些缺失降低了规范分，但整体可读性和基本治理尚可。
技能文档描述了完整的 API 和 MCP 功能，但没有任何实际输出或可验证的演示来证明其效果。静态审查无法验证价值主张，且没有第三方执行证据支持代表性输出。因此，有效性被限制在低水平，因为无法确认结果是否正确或直接可用。
仓库包含 CI 工作流（benchmarks.yaml、ci-docker.yaml），但它们是针对整个项目的，未专门验证此技能文档的内容。e2e 测试文件存在，但与本技能的直接关联不大，且来源是自动生成的（alef），不构成独立核实。因此，可验证性被限制在低水平，因为关键声明缺乏可复现的、独立的证据。
- CORS 默认为 permissive，若在生产环境未设置 CORS_ALLOWED_ORIGINS，可能导致跨站请求伪造风险；部署时务必配置受限来源。
- 技能文档未明确权限需求和用户确认机制；若将 API 集成到敏感环境，请确保遵循最小权限原则并增加确认步骤。
- 静态审查无法验证技能的实际执行结果；建议在真实环境中测试关键路径（如 /extract 端点）后再采用。
- 发布者身份未经验证，且技能文档未提供版本历史和变更日志；依赖此技能时应注意维护责任和更新路径的明确性。
这个 Skill 能做什么，适合哪些场景？
此技能在 Rust 中实现了 Xberg 文档提取引擎的双 REST API + MCP 服务器。它构建了一个带中间件的 Axum + Tokio 服务器，提供用于文件上传、URL 提取、批处理、缓存和格式列表的 REST 端点，以及用于工具调用、资源和提示的 MCP 端点。MCP 集成使 Claude 等 AI 代理能够直接调用提取函数，包括提取、批量提取和获取能力。该技能涵盖了服务器设置、路由、缓存策略、错误处理和与 Claude Desktop 的集成，并配有为 RAG 工作流设计的提示。
构建一个 Axum + Tokio 服务器，提供 REST API（端点如 POST /extract、POST /extract-url、GET /formats、GET /health、POST /batch、GET /cache/stats、DELETE /cache）和 MCP 端点（如 POST /mcp/tools、POST /mcp/tools/call）。应用中间件：正文大小限制（默认 100MB）、CORS、跟踪日志。实现基于 SHA256 文件内容的 LRU 缓存（默认 1000 条）。注册 MCP 工具：提取、批量提取、获取能力；资源：格式、功能、API 参考；提示：为 RAG 提取、批量文档处理。支持 HTTP 和 stdio 传输。提供环境配置（如 XBERG_PORT、XBERG_ENABLE_OCR）及错误处理，将 ApiError 映射到 HTTP 状态码。
- 开发者希望部署自托管的文档提取 API 服务，以支持多格式(PDF、Office、图像)。
- AI 代理(如 Claude)需要通过 MCP 协议直接从代理界面提取文档文本和元数据。
- 需要带缓存和批处理的异步处理高吞吐量文档提取工作负载的团队。
- 希望将提取功能集成到现有后端(如 Rust 服务)的过程，通过 REST 端点实现。
- 希望使用 MCP 提示标准化 RAG 提取工作流(如研究论文、合同)的用户。
这个 Skill 有哪些优点和局限？
- 提供 REST API 和 MCP 协议，支持广泛的客户端。
- 基于 SHA256 的 LRU 缓存，避免重复提取，提高性能。
- 详细的错误处理，并附有可操作的重建消息。
- 灵活的配置，支持大小限制、功能切换和 CORS。
- 支持异步和批处理，适合高吞吐量工作负载。
- 文档未明确说明从仓库构建的具体步骤。
- 缺少对 Windows 或非 Linux 平台的实际测试证据。
- MCP 工具数量有限(仅三个已实现的工具)。
- 缓存大小受内存限制，可能不适合超大型文件库。
- 环境中没有提到认证/授权机制，仅支持基本的 CORS 配置。
如何安装这个 Skill？
从 GitHub 仓库克隆或获取 xberg-io/xberg 仓库。在 Rust 环境中构建项目(需要 Rust 工具链)。该技能是集合的一部分；有关完整安装说明，请参阅仓库 README。未提供此技能独立的安装步骤。
如何使用这个 Skill？
在 crates/xberg-cli 中使用 CLI 启动服务器：xberg serve --host 0.0.0.0 --port 8000。或者，通过 CLI 启动 MCP 服务器：xberg mcp --transport stdio。对于 Claude Desktop，在配置中添加入口，例如：{"mcpServers": {"xberg": {"command": "xberg-mcp", "env": {"XBERG_API_BASE": "http://localhost:8000", "XBERG_MCP_TRANSPORT": "stdio"}}}。然后 AI 代理可以调用 MCP 工具，如提取。配置环境变量，如 XBERG_ENABLE_OCR 或 XBERG_CACHE_SIZE。