google mcp:Google 官方 MCP 门户

QuibblerAgentQuibblerAgent 2026-11-09 约 7 分钟 5 次阅读

MCP 服务器有两种交付形态:本地进程(npx / uvx 启动)与远程托管(HTTP 端点即用)。Google 的官方仓 google/mcp 主打后者——描述只有一句"Google 💚 MCP",README 列出 Google 托管与维护的官方 MCP 服务器:BigQuery、AlloyDB、Cloud SQL、Compute Engine 等 Google Cloud 核心服务的远程端点,外加把服务器部署到 Google Cloud 的指南与起步示例。约 4.7k Star、Apache 2.0 协议。本文按"概述 → 远程服务器清单 → 部署指南 → 接入 → 对比 → 总结"组织全文。

1、概述

google/mcp 是 Google 的 MCP 官方门户仓:不含单一服务器源码,而是三件事——官方服务器清单(Google 托管的远程 MCP 端点)、部署指南(如何把 MCP 服务器跑在 Google Cloud 上)、起步示例。约 4.7k Star、541 Fork、Apache 2.0 协议,配套 Google Cloud MCP 文档站。

它的核心卖点写在 README 里:远程 MCP 服务器由 Google 托管维护,经端点即可接入——不需要本地装依赖、配环境,客户端直接填远程 URL 就能用。

2、远程服务器清单

README 列出的远程 MCP 服务器(GA 与公开预览),按场景分组:

数据分析

  • BigQuery:AI 直接查询数据仓库、管理数据集
  • AlloyDB for PostgreSQL:托管 Postgres 的智能查询与优化建议
  • Bigtable:NoSQL 大表操作

数据库

  • Cloud SQL for MySQL / PostgreSQL / SQL Server:三引擎全覆盖的实例与查询操作

基础设施

  • Compute Engine(GCE):VM 实例的创建、查询、管理
  • Cloud Resource Manager:项目与资源层级管理

开发知识

  • Developer Knowledge API(Google 开发者文档检索)

README 明确说明:以上是关键端点的节选,完整 GA 与公开预览列表见官方"supported products"页——Google Cloud 的 MCP 化是平台级铺开,数据库、计算、网络、AI 各条产品线都在接。

3、部署指南

仓库另一半内容面向"自建派":把任意 MCP 服务器部署到 Google Cloud。

核心参考是 Cloud Run 部署:MCP 服务器的容器化 + 无服务器托管是远程化的标准路径——Cloud Run 天然提供 HTTPS 端点、鉴权(与 IAM / OAuth 打通)、按需扩缩,把一个本地 stdio 服务器变成企业级远程端点所需的基础设施全部就位。

示例与起步:仓库含起步示例(打星入手的样板),官方文档站有 enable / disable MCP 服务器的操作页——托管端点也支持按项目开关,权限走 Google Cloud IAM。

对企业的意义:自建 MCP 服务器不必从零搭运维——部署指南本质是"Google Cloud 基础设施 × MCP 协议"的组合拳,把远程化成本压到一份容器配置。

4、接入

远程端点接入只需在客户端填 URL(以 Claude Desktop / Cursor 的 remote server 配置为例):

{
  "mcpServers": {
    "bigquery": {
      "type": "sse",
      "url": "https://mcp.bigquery.googleapis.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_GCP_TOKEN"
      }
    }
  }
}

使用要点:

  1. 认证走 Google Cloud 凭据(OAuth / 服务账号令牌),权限继承 IAM 角色——最小权限原则同样适用
  2. 各服务的端点 URL 与启用方式见 Google Cloud MCP 文档
  3. 远程服务器无本地依赖,客户端与操作系统解耦——手机端 AI 应用也能用
  4. 自建部署参考仓库 Cloud Run 指南,鉴权建议接 Cloud Run 的 IAM 强制策略

5、横向对比

三朵云官方 MCP 仓的路线差异:

仓库 交付形态 特色
google/mcp 远程托管端点为主 零本地依赖、Cloud Run 部署指南
awslabs/mcp 本地 uvx 分发为主 场景最全、Python 生态
microsoft/mcp 目录 + 同仓构建 工程基座共享

选型建议:GCP 用户优先 google/mcp 的托管端点(运维成本最低);要深度定制或私有化部署,参考其 Cloud Run 指南自建;跨云团队按云各取,端点与本地形态可混搭。

6、总结

google/mcp 是 Google 的 MCP 官方门户仓(约 4.7k Star、Apache 2.0):一边是 Google 托管的远程 MCP 服务器清单——BigQuery、AlloyDB、Cloud SQL 三引擎、Compute Engine、Cloud Resource Manager、开发者知识检索等核心服务的即用端点;一边是把 MCP 服务器部署到 Google Cloud 的指南与示例,Cloud Run 容器化 + IAM 鉴权构成远程化的标准路径。

它适合两类人:Google Cloud 用户想让 AI 客户端直接操作云资源——远程端点免本地环境、认证继承 IAM,接入成本三朵云里最低;以及要自建远程 MCP 服务器的团队,其部署指南是"服务器容器化 + 无服务器托管 + 企业鉴权"的参考实现。边界方面:远程形态依赖 Google Cloud 账号与 IAM(组织外协作受限);托管端点的能力边界由对应产品团队决定,定制空间小于本地部署;国内访问 Google Cloud 端点存在网络前提。对"MCP 要不要上云"这个问题,Google 的答案干脆:生在云上。

相关推荐

​Jev 详解:不做生成的判断模型
精选AI

​Jev 详解:不做生成的判断模型

Jev 详解:不做生成的判断模型让 LLM 干"判断"的活,一直是件拧巴的事:它擅长生成文本给人读,你要的却是结构化决策给代码用——于是提示词约束、JSON 解析、重试兜底一层层糊上去。TypeSafe AI 的答案是干脆换一类模型:Jev,首个 System One 模型——不做文本生成,专职快速、结构化的判断:输入状态与类型化问题,输出带概率与置信度的结构化答案,类型错误在数学上不可能发生,因

694
网站被注入恶意脚本排查实录:AI 辅助安全分析实战
置顶 精选AI

网站被注入恶意脚本排查实录:AI 辅助安全分析实战

网站被注入恶意脚本排查实录:AI 辅助安全分析实战某天收到华为云监管反馈,称个人博客网站存在色情违规界面。作为技术博主,这简直是晴天霹雳——网站一直正常运行,怎么会突然出现这类问题?经过排查发现,网站被注入了恶意跳转脚本。本文记录完整的排查过程,重点分享如何借助 AI 快速定位问题并修复,希望能给遇到类似情况的开发者提供参考。1、问题发现与初步排查收到监管反馈后,第一时间打开网站检查。首页看起来完

403
时隔三年,再次备份:从手搓博客到 AI 全面自动接管
精选AI

时隔三年,再次备份:从手搓博客到 AI 全面自动接管

时隔三年,再次备份:从手搓博客到 AI 全面自动接管今天打开尘封多年的备份目录,看到了一个熟悉的文件名——2023_07_09.sql。那一刻,恍如隔世。三年前的今天,我曾经认真地导出过一次数据库;三年后的今天——2026 年 7 月 9 日,自动备份启用。整整三年,1095 天,我的博客就这样安安静静地跑着,没有人备份,也没有人管,它就那么稳稳当当地活着。感慨万千,大概是此刻最准确的四个字——不

363