Neon MCP Server

用于与Neon Management API和数据库交互的MCP服务器。

什么是MCP服务器？

MCP信息

镜像构建信息

可用工具（19个）

---## 工具详情#### 工具：**__node_version**获取MCP服务器使用的Node.js版本

---#### 工具：**complete_database_migration**当用户确认迁移已准备好应用到主分支时，完成数据库迁移。此工具还会通知客户端，prepare_database_migration工具创建的临时分支已被删除。

---#### 工具：**complete_query_tuning**通过将更改应用到主分支或丢弃更改来完成查询调优会话。

重要注意事项： 在运行此工具之前：

• 使用建议的DDL语句通过run_sql在临时分支中测试更改
• 使用原始查询和临时分支通过explain_sql_statement测试

此工具是在prepare_query_tuning工具之后最终将更改应用到主分支的唯一方式。 不得使用prepare_database_migration或其他工具来应用查询调优更改。 必须传递从prepare_query_tuning工具获取的tuning_id，而不是临时分支ID作为tuning_id给此工具。 必须将prepare_query_tuning工具中使用的临时分支ID作为TEMPORARY branchId传递给此工具。 此工具可选接收第二个分支ID或名称，可用于代替主分支来应用更改。 即使用户拒绝更改，也必须在prepare_query_tuning工具之后调用此工具，以确保临时分支的正确清理。

此工具将：

1. 如果获得批准，将建议的更改（如创建索引）应用到主分支（或指定分支）
2. 处理临时分支的清理
3. 即使拒绝更改，也必须调用以确保正确清理

工作流程：

1. prepare_query_tuning建议更改后
2. 用户查看并批准/拒绝更改
3. 调用此工具以：
   • 将批准的更改应用到主分支并清理
   • 或仅在拒绝更改时进行清理

---#### 工具：**create_branch**在Neon项目中创建分支

---#### 工具：**create_project**创建新的Neon项目。如果需要创建数据库，请使用此工具。

---#### 工具：**delete_branch**从Neon项目中删除分支

---#### 工具：**delete_project**删除Neon项目

---#### 工具：**describe_branch**获取分支中所有对象的树形视图，包括数据库、模式、表、视图和函数

---#### 工具：**describe_project**描述Neon项目

---#### 工具：**describe_table_schema**描述Neon数据库中表的模式

---#### 工具：**explain_sql_statement**通过在数据库中运行EXPLAIN (ANALYZE...)来描述SQL语句的PostgreSQL查询执行计划

---#### 工具：**get_connection_string**获取Neon数据库的PostgreSQL连接字符串，所有参数均为可选

---#### 工具：**get_database_tables**获取Neon数据库中的所有表

---#### 工具：**list_projects**列出账户中的所有Neon项目

---#### 工具：prepare_database_migration<use_case> 此工具通过自动生成和执行DDL语句来执行数据库模式迁移。

支持的操作： 创建操作：

• 添加新列（例如："Add email column to users table"）
• 创建新表（例如："Create posts table with title and content columns"）
• 添加约束（例如："Add unique constraint on users.email"）

修改操作：

• 修改列类型（例如："Change posts.views to bigint"）
• 重命名列（例如："Rename user_name to username in users table"）
• 添加/修改索引（例如："Add index on posts.title"）
• 添加/修改外键（例如："Add foreign key from posts.user_id to users.id"）

删除操作：

• 删除列（例如："Drop temporary_field from users table"）
• 删除表（例如："Drop the old_logs table"）
• 删除约束（例如："Remove unique constraint from posts.slug"）

此工具将：

1. 解析自然语言请求
2. 生成适当的SQL
3. 在临时分支中安全执行
4. 在应用到主分支前验证更改

项目ID和数据库名称将自动从请求中提取。 如果未提供数据库名称，将使用默认的neondb或第一个可用的数据库。 </use_case>

1. 创建临时分支 2. 在该分支中应用迁移SQL 3. 返回迁移详情供验证

<important_notes> 执行此工具后，必须：

1. 使用run_sql工具在临时分支中测试迁移
2. 请求确认后再继续
3. 使用complete_database_migration工具将更改应用到主分支 </important_notes>

对于如下迁移： ALTER TABLE users ADD COLUMN last_login TIMESTAMP;

应使用以下命令测试： SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'users' AND column_name = 'last_login';

可以使用run_sql在该工具创建的临时分支中测试迁移。

<next_steps> 执行此工具后，必须遵循以下步骤：

1. 使用run_sql在临时分支上验证更改
2. 按照以下说明响应客户端：

<response_instructions> 提供请求更改的简要确认，并请求迁移提交批准。

响应中必须包含以下所有字段：

• 迁移ID（提交所需，必须首先显示）
• 临时分支名称（始终包含确切的分支名称）
• 临时分支ID（始终包含确切的ID）
• 迁移结果（包含简要的成功/失败状态）

即使工具响应中缺少某些字段，也应使用"未提供"等占位符，而不是省略字段。

<do_not_include> 重要：响应中不得包含任何技术实现细节，例如：

• 数据类型（例如：不得提及列是否为boolean、varchar、timestamp等）
• 列规范或属性
• SQL语法或语句
• 约束定义或规则
• 默认值
• 索引类型
• 外键规范

保持响应仅关注高层级更改的确认和请求批准。

不正确："我已向posts表添加了boolean类型的is_published列..." 正确："我已向posts表添加了is_published列..." 我已确认请求的更改已成功应用到临时分支。是否要将迁移[migration_id]提交到主分支？

迁移详情：

• 迁移ID（提交所需）
• 临时分支名称
• 临时分支ID
• 迁移结果

</response_instructions>

3. 如果获得批准，使用带有migration_id的complete_database_migration工具 </next_steps>

<error_handling> 出错时，此工具将：

1. 自动尝试对完全相同的操作重试一次
2. 如果重试失败：
   • 终止执行
   • 返回错误详情
   • 不尝试任何其他工具或替代方案

错误响应将包含：

• 原始错误详情
• 重试尝试确认
• 最终错误状态

重要：重试失败后，必须完全终止当前流程。不要尝试使用替代工具或解决方法。 </error_handling>

参数	类型	描述
params	object

---#### 工具：prepare_query_tuning<use_case> 此工具通过分析执行计划并建议优化，帮助开发人员提高慢查询或DML语句的PostgreSQL查询性能。

此工具将：

1. 创建用于测试优化的临时分支并记住分支ID
2. 提取和分析当前查询执行计划
3. 提取计划中引用的所有完全限定表名（schema.table）
4. 使用describe_table_schema收集每个引用表的详细模式信息
5. 建议并实施改进，例如：
   • 基于表模式和查询模式添加或修改索引
   • 查询结构修改
   • 识别潜在性能瓶颈
6. 使用run_sql将更改应用到临时分支
7. 比较更改前后的性能（但仅在临时分支上通过传递分支ID给所有工具）
8. 使用complete_query_tuning工具继续下一步（在主分支上）

项目ID和数据库名称将自动从请求中提取。 调用其他工具时将添加临时分支ID。 如果未指定，默认数据库为neondb。

重要：此工具是查询调优工作流的一部分。任何建议的更改（如创建索引）必须首先使用run_sql工具应用到临时分支，然后使用complete_query_tuning工具应用到主分支，而不是prepare_database_migration工具。 要使用complete_query_tuning工具应用，必须传递tuning_id，而不是临时分支ID。 </use_case>

1. 创建临时分支 2. 分析当前查询性能并提取表信息 3. 实施和测试改进（使用run_sql工具进行模式修改，使用explain_sql_statement工具进行性能分析，但仅在步骤1创建的临时分支上传递相同的分支ID给所有工具） 4. 返回调优详情供验证

<important_notes> 执行此工具后，必须：

1. 查看建议的更改
2. 在临时分支上验证性能改进 - 通过run_sql应用更改并再次运行explain_sql_statement
3. 决定保留或丢弃更改
4. 使用complete_query_tuning工具将更改应用或丢弃到主分支

不要使用prepare_database_migration工具应用查询调优更改。 始终使用complete_query_tuning以确保更改被正确跟踪和应用。

注意：

• 某些操作（如创建索引）在大表上可能需要大量时间
• 表统计信息更新（ANALYZE）不会自动执行，因为它们可能运行时间较长
• 表统计信息维护应由PostgreSQL自动分析或计划维护作业处理
• 如果怀疑统计信息过时，建议将ANALYZE作为单独的维护任务运行 </important_notes>

对于如下查询： SELECT o.*, c.name FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'pending' AND o.created_at > '2024-01-01';

此工具将：

1. 提取引用表：public.orders, public.customers
2. 收集两个表的模式信息
3. 分析执行计划
4. 建议改进，例如：
   • 在orders(status, created_at)上创建复合索引
   • 优化连接条件
5. 如果确认，使用run_sql将建议的更改应用到临时分支
6. 比较更改前后的执行计划和性能（但仅在临时分支上传递分支ID给所有工具）

<next_steps> 执行此工具后，必须遵循以下步骤：

1. 查看执行计划和建议的更改
2. 按照以下说明响应客户端：

<response_instructions> 提供性能分析的简要摘要，并请求批准在临时分支上应用更改。

响应中必须包含以下所有字段：

• 调优ID（完成所需）
• 临时分支名称
• 临时分支ID
• 原始查询成本
• 改进后的查询成本
• 引用表（列出计划中找到的所有表）
• 建议的更改

即使工具响应中缺少某些字段，也应使用"未提供"等占位符，而不是省略字段。

<do_not_include> 重要：响应中不得包含任何技术实现细节，例如：

• 确切的索引定义
• PostgreSQL内部设置
• 复杂查询重写
• 表分区详情

保持响应专注于高层级更改和性能指标。 </do_not_include>

我已分析您的查询，发现可能的改进可将执行时间减少[X]%。 是否要应用这些更改以提高性能？

分析详情：

• 调优ID: [id]
• 临时分支: [name]
• 分支ID: [id]
• 原始成本: [cost]
• 改进成本: [cost]
• 引用表:
  • public.orders
  • public.customers
• 建议的更改:
  • 为频繁过滤的列添加索引
  • 优化连接条件

要应用这些更改，我将在获得您的批准后使用'complete_query_tuning'工具，并向其传递tuning_id，而不是临时分支ID。 </response_instructions