用自然语言查数据库：Cursor与MCP协议实战解析

当SQL遇上自然语言

你有没有想过，直接用英语向数据库提问，而不是写一行行SQL语句？比如问一句"上个月各地区的出货量是多少"，然后看着工具自动从公司私有数据库中拉出真实数据？

这不是科幻场景。一个YouTube短视频演示了这样的工作流：用户在Cursor中提出业务问题，Cursor没有直接连接数据库，而是调用了一个工具，最终返回了四条与SQL查询结果完全吻合的数据。这背后发挥关键作用的，是MCP（Model Context Protocol，模型上下文协议）。

本文将拆解这个过程的底层机制，帮助你理解为什么这种方式比传统数据库查询更安全、更可扩展。

Cursor如何"隔空"拿到数据库数据？

Cursor本身并不知道如何连接数据库服务器，也不知道如何用数据库能听懂的语言去"说话"。它做的事情非常单一：调用一个工具（call a tool）。

这个工具本质上是运行在本机上的一个Python程序中的函数。当Cursor发起调用时，该函数会向数据库服务器发送一条SQL查询，数据库服务器再将结果——演示中是四行数据——返回给这个Python程序，最后由程序把数据传回Cursor的聊天窗口。

所以，Cursor不需要内置数据库驱动，不需要知道IP地址和端口，更不需要处理认证细节。它只需要知道"有一个工具可以帮我拿数据"。这种分工把复杂性和安全边界都推到了MCP服务器一侧。

MCP协议：共享规则才是关键

MCP全称Model Context Protocol，即模型上下文协议。它是一套共享的规则集合，定义了模型如何请求另一个程序运行某个功能，以及那个程序如何把结果送回来。

在这个架构中，角色划分非常清晰：

• Cursor是MCP客户端：它只负责发出工具调用请求，不直接接触数据库。
• Python程序是MCP服务器：它暴露工具、执行具体逻辑、与数据库通信。

这种设计的精妙之处在于抽象层的价值。任何支持MCP协议的客户端都可以复用同一套服务器，而不需要为每个数据库或每个数据源重新写连接逻辑。协议本身成为了模型与外部世界之间的通用接口。

MCP 由 Anthropic 于 2024 年 11 月开源发布，采用 JSON-RPC 2.0 作为底层消息格式。它的设计目标并非绑定某一家模型厂商，而是成为一个开放标准，让不同的大模型客户端都能以统一方式接入外部数据源和工具。协议定义了三类核心能力：resources（可读取的上下文数据）、tools（可调用的函数）、prompts（可复用的提示模板）。围绕 MCP，社区已经出现了大量现成服务器，覆盖文件系统、GitHub、Slack、Postgres 等常见系统，开发者可以直接复用而无需从零编写连接逻辑。这也正是原文所说的「通用接口」价值的来源——协议一旦统一，生态便能横向扩展。

STDIO如何省去端口和服务器配置

当你在Cursor中提出问题时，Cursor会自动查找已注册的工具并启动对应的MCP服务器进程。整个过程不需要你手动运行一个独立的服务端程序，也不需要连接任何端口或URL。

实现这一点的核心机制是STDIO（标准输入和标准输出）。Cursor和MCP服务器进程共享这两个流：

• Cursor把工具请求写入程序的标准输入；
• 程序把工具执行结果写回标准输出。

因为共享了这两个流，通信就变成了简单的读写操作，省去了网络配置的麻烦。Cursor会管理这个服务器进程的生命周期——只要工具还需要用，进程就保持运行；用完之后，无需手动清理。

STDIO 是进程间通信（IPC）中最基础的一种形式。每个进程在启动时都会自动获得三个标准流：标准输入（stdin，文件描述符 0）、标准输出（stdout，文件描述符 1）、标准错误（stderr，文件描述符 2）。父进程可以通过管道（pipe）把它们连接到子进程，从而在不经过网络栈的情况下交换数据。MCP 的 stdio 传输正是利用了这一点：客户端启动服务器子进程后，双方通过 stdin/stdout 传递 JSON-RPC 消息，而 stderr 通常被保留用于日志输出，避免污染协议消息。相比 HTTP 或 SSE 传输，stdio 的延迟更低、无需开放端口，天然适合本地工具场景，但它的局限是无法跨机器使用——需要远程访问时仍要切换到基于网络的传输方式。

工具暴露是安全边界的守门人

视频中使用了三个工具来演示数据库访问：

1. list_tables：列出数据库中有哪些表；
2. describe_table：查看某张表的列结构；
3. run_query：执行一条SQL语句。

这三个工具构成了MCP服务器控制模型访问权限的全部手段。如果一个工具没有被提供，模型就无法通过这个MCP服务器获取意外信息。换句话说，模型能看到什么、能操作什么，完全由MCP服务器暴露的工具集合决定。

这比直接给模型一个数据库连接字符串要安全得多。你可以限制查询范围、过滤敏感表、甚至对run_query做SQL审查，而模型对此毫无感知。它只是调用工具，并接受工具返回的结果。

让大模型直接生成 SQL 并执行，长期面临一个固有风险：模型可能被用户输入中的提示注入攻击诱导，生成 DROP TABLE、UPDATE 或跨表越权查询等危险语句。MCP 的工具化设计提供了结构性的缓解。由于模型只能调用已注册的工具，开发者可以在 run_query 内部加入白名单校验、只读连接、行数上限、超时控制、SQL 解析审查等防护措施，而模型对此完全无感知。更进一步，可以把常见查询封装成参数化的专用工具（如 get_monthly_shipment_by_region），让模型连 SQL 都不需要生成，从根本上消除注入面。这种「能力即权限」的思路，是 MCP 相比裸数据库连接在安全上的关键差异。

自然语言查数据库的实用价值

从演示来看，Cursor返回的四条数据与预期SQL查询结果一致，说明这条链路是可靠的。但更有价值的是它揭示了一种趋势：业务人员可以用自然语言直接获取数据洞察，而不必依赖数据团队写SQL。

当然，这并不意味着SQL会消失。MCP服务器中的run_query工具仍然在执行SQL，只是写SQL的人从业务用户变成了工具开发者或数据工程师。他们把常见的查询模式封装成工具，业务用户则用自然语言触发。这是一种新的分工方式，兼顾了效率与可控性。

对于希望快速搭建内部数据问答系统的团队来说，MCP + Cursor的组合提供了一条低门槛路径：你只需要一个Python程序、几个工具函数，以及一个支持MCP的客户端。剩下的交给协议去处理。