跳到主要内容
翻译页面

本页面由 AI 辅助从英文翻译而来。如两者存在差异，以英文版本为准。

StackQL vs 自定义 MCP 服务器

自定义 MCP 服务器将某个特定的 API 或工作流封装为供 AI 智能体使用的手写工具；StackQL 内置的 MCP 服务器则通过一小组通用、自描述的工具加上 SQL，公开所有受支持的云和 SaaS Provider 的完整接口面。这一对比的双方，一方是按领域整理工具，另一方是为智能体提供一个覆盖所有领域的可查询抽象。

何时使用哪一个​

在以下情况下构建自定义 MCP 服务器：

  • 领域较窄且操作较少：对于该特定工作流，十几个命名清晰、schema 严谨的工具在可靠性上可以胜过通用接口。
  • 你需要在智能体和 API 之间加入大量业务逻辑：审批、数据富化，以及在智能体看来应当是一个原子工具的多步骤事务。
  • 目标 API 是内部的或专有的，并且没有公开规范对其进行描述。

在以下情况下使用 StackQL 的 MCP 服务器：

  • 领域是云和 SaaS 基础设施，即 AWS、Azure、Google Cloud、GitHub、Databricks、Snowflake、Okta 以及 Provider 注册表中的其余部分，其操作数量使得按操作提供工具不切实际。
  • 你希望智能体在运行时发现能力（list_providers -> list_services -> list_resources -> list_methods -> describe_method），而不是局限于某人预先设想到的工具。
  • 你需要受治理的写操作：四种模式的安全契约（read_only、safe、delete_safe、full_access），配有基于征询（elicitation）的人工审批和始终开启的审计日志，而不是由你自己编写和维护的安全逻辑。
  • 你希望用一个凭据和策略接口面覆盖整个环境，而不是为每个 Provider 定制一个服务器。

这两种方法可以组合使用：团队通常运行 StackQL MCP 来提供通用的基础设施访问，同时为专有的内部系统运行小型的自定义 MCP 服务器。

token 经济学​

智能体工具的实际约束是上下文。工具定义在任何工作开始之前就会占用智能体的上下文窗口，而且工具选择的准确率会随着工具数量的增长而下降。仅将 AWS 按操作发布为工具，就意味着数千个定义。StackQL 的设计将发布的工具集控制在不到 15 个（发现、描述、验证、执行、注册表管理），并将表达能力转移到 SQL 中，这是当前每个模型都已能流畅编写的语言。智能体每个任务的 token 成本是一段简短的 SQL 字符串，而不是一次工具 schema 协商。这一论点在为什么 SQL 是云 API 的强大接口中展开。

示例​

针对 StackQL 的 MCP 服务器的一次智能体会话，在使用 list_methods 发现必需参数之后：

SELECT name, visibility, default_branch
FROM github.repos.repos
WHERE org = 'stackql';

同一个工具（run_select_query）既处理这条查询，也处理针对任何 Provider 的任何其他读取；变更请求则经由 run_mutation_query 路由，由服务器模式决定它们是继续执行、需要审批还是被拒绝。