Google Cloud給地圖、數(shù)據(jù)庫、虛擬機(jī)都配了官方MCP服務(wù)，唯獨日歷這塊留了白。更魔幻的是，Google Workspace團(tuán)隊今年3月確實上線過日歷MCP，48小時內(nèi)又親手撤掉?，F(xiàn)在GitHub上1100多顆星星的社區(qū)項目，成了開發(fā)者唯一靠譜的選項。

13個工具覆蓋日歷全生命周期

nspady/google-calendar-mcp這個項目目前迭代到v2.6.1，功能拆得夠細(xì)。讀操作7個：列日歷、列事件、搜事件、查忙閑、獲取當(dāng)前時間、甚至列出Google日歷的顏色編碼——做產(chǎn)品的人都知道，顏色同步往往是體驗細(xì)節(jié)里最磨人的部分。

寫操作5個，從單條創(chuàng)建到批量插入（v2.5.0新增），再到更新、刪除、回復(fù)邀請。管理員功能1個：管理多賬號綁定。這套組合拳打下來，AI助手基本能替代你80%的日歷操作。

多賬號支持是這項目的殺手锏。打工人的日歷往往散落在公司G Suite、個人Gmail、副業(yè)賬號之間，官方API的OAuth流程本就繁瑣，自己搭服務(wù)還要處理token刷新、權(quán)限隔離。這個項目把「manage-accounts」封裝成單個工具，相當(dāng)于把基礎(chǔ)設(shè)施的臟活攬了過去。

評分4/5，扣掉的0.5分很實在：OAuth 2.0 with PKCE的配置門檻還在，以及——Google官方缺席帶來的長期維護(hù)隱憂。

Google的反復(fù)：上線、撤回、裝死

時間線值得復(fù)盤。2026年3月初，Google Workspace CLI悄悄合并了PR #275，新增日歷MCP支持。開發(fā)者還沒來得及寫教程，兩天后同一批代碼被回滾。官方?jīng)]給解釋，留下一個「workspace-developer.goog/mcp」的文檔站點，點進(jìn)去只有只讀接口，寫操作全鎖。

這種操作在Google不算新鮮。還記得Google Reader嗎？產(chǎn)品決策的隨機(jī)性，某種程度上比明確的「不做」更消耗生態(tài)信任。MCP（Model Context Protocol，模型上下文協(xié)議）作為Anthropic主推的AI工具調(diào)用標(biāo)準(zhǔn)，Google的態(tài)度曖昧得很：地圖、BigQuery、Compute Engine都給托管服務(wù)，日歷偏偏卡住。

可能的解釋有幾種。日歷數(shù)據(jù)的隱私敏感度高于地圖坐標(biāo)？Workspace團(tuán)隊與Cloud團(tuán)隊的內(nèi)部優(yōu)先級拉扯？或者單純是MCP標(biāo)準(zhǔn)迭代太快，官方不想過早站隊？

沒人知道答案。但結(jié)果是確定的：社區(qū)開發(fā)者nspady的個人項目，成了事實標(biāo)準(zhǔn)。

社區(qū)項目的生存法則

看GitHub倉庫的release記錄，23個版本迭代，v2.5.0剛加了批量創(chuàng)建。這種節(jié)奏說明維護(hù)者在真實場景里用這工具——不是demo性質(zhì)的開源玩具。

技術(shù)選型上也有取舍。沒選Google官方的Workspace API SDK，而是直接對接Calendar API v3，再用MCP協(xié)議包一層。好處是靈活，壞處是Google哪天改API，項目得跟著追。這就是4分里那0.5分的代價。

對比之下，Google Cloud的托管MCP服務(wù)確實省心，但覆蓋范圍有限。地圖API能查路線，BigQuery能跑SQL，可打工人的日常戰(zhàn)場在日歷、郵件、文檔——這些Workspace核心產(chǎn)品，Google反而按兵不動。

一個觀察：MCP生態(tài)正在復(fù)制早期Chrome擴(kuò)展的故事。官方猶豫的地方，社區(qū)填坑；等市場驗證了需求，巨頭再下場收編。區(qū)別是這次AI助手的集成更深，數(shù)據(jù)權(quán)限更敏感，收編的難度和阻力也會更大。

你現(xiàn)在用AI助手管日歷嗎？是信社區(qū)項目的迭代速度，還是等Google哪天想通了再遷移？