最近，我一直在全國各地奔走，透過我們的「使用 Cloud Run 加速 AI」研討會，幫助工程師學習如何在 Cloud Run 上無伺服器地建立 MCP 伺服器和 AI 代理程式。學員們常問：我如何將所學應用到我的實際專案中？這篇部落格講述了我如何利用研討會上的第一個實作實驗，建構出一個能在我日常工作中節省時間和精力的工具！

身為Google Kubernetes Podcast的共同主持人，我非常喜歡與大家交流，學習各種酷炫的技術和應用案例。但和任何內容系列一樣，製作和發布每一期節目都需要投入大量的時間和精力。在本文中，我將解釋我是如何以及為什麼建立 MCP 伺服器來簡化和加速我們的發布流程的。您也可以在 GitHub 上查看我的 podcast-assistant-mcp 伺服器的程式碼，親自體驗我的解決方案！

讓播客發布更快更輕鬆

製作播客涉及很多步驟：挑選嘉賓和主題、安排採訪、剪輯節目等等。你可能會覺得發布應該是整個過程中最快的部分——只需點擊一個按鈕就發布了，對吧？ ！唉，親愛的讀者，我多麼希望它真的如此快速方便。

每一集的發布流程大致如下：

1. 認真收聽節目，並寫下節目筆記。 （這或許是整個過程中最耗時、最需要投入精力的一步。）

2. 將最終音訊上傳到我們的發布平台，並填寫所有元資料欄位（節目註釋、標籤等）。

3. 透過在倉庫中發起拉取請求來更新kubernetespodcast.com （我們的網站是用Hugo建置的）。

4. 在社群媒體（X、LinkedIn、BlueSky、Reddit 等）上宣傳新影集。

我們出版流程中大量的人工步驟非常耗時。我需要一種更有效率的方法，而我看到了人工智慧可以提供幫助的機會。

第一步：基於人工智慧的腳本

人工智慧擅長內容概括和轉換。我們出版流程中最耗時的環節很多本質上都是內容概括任務。這為我們提供了一個絕佳的機會，可以利用人工智慧來撰寫節目筆記和社交媒體貼文等出版材料。

為了驗證我的理論，即人工智慧可以透過這些摘要步驟節省我的時間，我建立了一個簡單的 Python 腳本，該腳本：

• 輸入的是音訊檔案。

• 利用人工智慧將音訊轉換為文字稿。

• 利用文字稿撰寫了節目筆記和社群媒體貼文的草稿

只需一個簡單的 Python 腳本，我就大大減少了自己花在仔細收聽節目並記筆記上的時間。雖然我仍然會審查和編輯所有發布的內容，但 AI 生成的節目筆記為我提供了工作基礎，最大限度地減少了我在收聽節目時頻繁停頓記筆記的需要。此外，產生的社群媒體草稿也簡化了貼文發布前的準備工作。我從 2025 年初開始定期使用這個腳本，它平均每集節目能節省 1.5 到 2 個小時，在過去的幾個月裡，它已經成為我發布流程中不可或缺的一部分。

但問題來了。你知道，我並不是 Kubernetes Podcast 的唯一主持人，發佈內容也不是每次都由我一個人負責。我這個省時省力的腳本的問題在於：**只有我一個人在使用！ ** 當然，我把腳本分享給了其他主持人，但由於它無法整合到他們現有的發布流程中，所以他們並沒有利用它來節省寶貴的發佈時間。

步驟 2：從本機腳本到可共享的 MCP 伺服器

為了節省合作主持人的時間，我開始探索如何更有效地分享我的自動化流程，並擴展初始腳本以進一步優化我們的發布工作流程。

最初，我設想開發一個功能全面的嚮導式網頁應用程式，用於管理整個流程，並加入「人工審核」環節。這種方法可以集中管理我們的發布工具和流程，簡化新主機商的入駐流程。

然後我不得不面對現實：

• 我是 Kubernetes/雲端基礎架構專家——但我沒有前端技能來快速建立多步驟 Web 應用程式！

• 許多用於發佈到我們所有平台的 API 都無法直接使用。 😞

最終，我還是沒有足夠的時間發展出如此全面的解決方案。因此，我回歸了古老的智慧：化繁為簡。為了解決我的問題，我真正需要的是一個團隊能夠輕鬆上手、立即節省時間的系統。同時，從長遠來看，我尋求的是一個可擴展的架構，能夠讓我根據時間的允許逐步建立理想的發布流程。

解決方案：建立一個 MCP（模型上下文協定）伺服器！這種方法有幾個關鍵優勢：

• 它擁有簡潔的使用者介面，主要透過後端程式碼實現（無需學習前端語言或函式庫）。

• 它與我們團隊已經在使用的Gemini CLI整合。這意味著他們無需學習任何新工具，也無需在工作流程中加入任何新工具！

• 它具有極強的可擴展性！我可以有時間的時候，逐步加入新的工具（例如 generate_hugo_post 或 publish_to_platform_x）。

• 利用現有資源：我利用兩份現有內容快速搭建了這個 MCP 伺服器：

* I was able to reuse the MCP Server design and deployment methodology from the first hands-on lab from our [Accelerate AI with Cloud Run workshop series](http://goo.gle/accelerate-ai), which demonstrates [running a secure MCP server on Cloud Run](http://goo.gle/aaiwcr-1).

* And to customize it to my use case, I converted the Python script I had already developed into an MCP server. The conversion was amazingly easy- I just integrated the FastMCP library and modified the output mechanism to ensure each function independently saved its output to a storage bucket.

Podcast Assistant MCP 伺服器的工作原理

我使用 FastMCP 和 Google 的 GenAI 庫建立了伺服器，我稱之為我的 podcast-assistant-mcp，所有元件都透過 Docker 容器化，並準備部署到Cloud Run 。

堆疊

這個專案很簡單。就像在實驗室裡一樣，我使用命令列工具 uv來管理依賴項，這意味著我有一個pyproject.toml 檔案來定義關鍵依賴項：

• FastMCP ：用於建立 MCP 伺服器本身。

• google-genai ：與Vertex AI 上的 Gemini 2.5 Flash 模型互動。

• google-cloud-storage ：用於讀取音訊檔案並將文字輸出寫入 Google Cloud Storage 儲存桶。

MCP 伺服器工具

我最初用 Python 腳本編寫這個專案的程式碼時，設計成順序執行，一個工具的輸出作為下一個工具的輸入。但在 MCP 伺服器中，每個元件都可以獨立呼叫，從而提供了更大的靈活性。例如，如果我們已經手動建立了節目筆記檔案（我們偶爾會這樣做），或者如果您已經有了文字稿，並想用它來生成社交媒體和部落格文章（我們可能會對舊節目這樣做），AI 播客助理足夠靈活，可以協助您完成它所支援的任何發布流程。它仍然可以完成所有工具的功能，並且知道如何以合理的順序執行這些功能！隨著我們為伺服器開發更多工具，這種靈活性將變得更加有用。

此專案由 3 個主要檔案組成： server.py檔案定義了 MCP 伺服器本身， Dockerfile檔案和pyproject.toml 檔案用於部署。

<a href="https://github.com/GoogleCloudPlatform/devrel-demos/blob/main/containers/podcast-assistant-mcp/server.py">server.py file</a>定義了 4 個主要工具， README 檔案中包含如何透過Gemini CLI存取這些工具的說明。通常，我們將所有生成的內容都視為初稿——我們會仔細審查和編輯所有即將發布的內容。

函數 1. generate_transcript(audio_file_uri: str, episode_name: str) -> str

這是起點。它接收一個 .mp3 或 .wav 檔案的 GCS URI，並使用詳細的提示將其轉錄。提示非常具體，要求輸入說話者標籤和時間戳，這對於製作節目筆記至關重要，之後我可以手動或使用品質評估工具來確認筆記的品質。然後，它將轉錄結果儲存到 GCS 並傳回新的 URI。

函數 2. generate_shownotes(transcript_gcs_uri: str, episode_name: str) -> str

此工具會讀取轉錄文字的 GCS URI。在我們的生產伺服器上，它會使用專門針對我們播客風格定制的提示符，也就是一個 Markdown 格式的 shownotes 文件，其中主要包含一系列連結，指向相關補充材料，供任何想要了解更多節目中提到的技術的人使用。

對於 GitHub 程式碼庫，我採用了一種更通用的節目筆記概念，用於總結每集內容。如果您想親自嘗試，可以隨時編輯提示訊息以使其工作方式有所不同！無論是在我們的生產環境還是從程式碼庫部署，此函數都會將 Markdown 格式的節目筆記檔案儲存到 GCS，並傳回該檔案的 URI。

函數 3. generate_blog_post(transcript_gcs_uri: str, episode_name: str) -> str

第三個函數會讀取播客文本，並產生一篇完整且引人入勝的 Markdown 格式部落格文章，並將結果儲存到 GCS。 MCP 伺服器的可擴充性在這裡發揮了一定的作用，因為kubernetespodcast.com目前還沒有部落格。我們計劃在未來某個時候實現部落格功能。此工具產生的草稿可以作為部落格頁面上線後的便利起點。我們將以此函數的輸出為起點，從而將更多時間用於確保內容的準確性、加入相關參考資料的連結，並確保節目要點能夠以博客文章的形式清晰呈現。

函式 4. generate_social_media_posts(transcript_gcs_uri: str, episode_name: str) -> str

最後，MCP 伺服器中的第四個工具會根據文字稿產生適用於 X（不超過 280 個字元）和 LinkedIn 的格式化草稿。與 MCP 伺服器的所有輸出一樣，我們會在發布前審核並編輯這些草稿。

部署

將其部署為 MCP 伺服器的全部意義就在於與我的合作主機共享，這意味著需要將其部署在 Cloud Run 上並啟用身份驗證——也就是說，只要我們告訴他們如何使用，任何人都可以使用！這也有助於簡化新主機的加入流程，尤其是在我們將發布流程的更多環節實現為工具之後。部署方面，我們使用了一個簡單的 Dockerfile 用於容器化，以及一個 pyproject.toml 檔案來處理依賴項。

力求完美：設計選擇

我在設計這個專案時特意做了一些選擇。如果你也打算搭建自己的MCP伺服器，不妨考慮一下這些因素。

選擇合適的型號

我最初的腳本使用了 Gemini 2.5 Pro，這是一個強大的內容生成模型。然而，我遇到了一個問題：Gemini CLI 在等待工具輸出時會逾時。在嘗試了各種可能的超時配置變更但均未成功後，我切換到了 Vertex AI 上的 Gemini 2.5 Flash。 Flash 的速度夠快，能夠在客戶端的超時限制內完成產生和儲存到儲存桶的操作，從而實現了可靠的工作流程執行。雖然其他型號也可用，但目前 Gemini 2.5 Flash 是我在此應用中的首選。

FastMCP 工具與提示

作為一項關鍵依賴項，FastMCP 提供了一項功能，允許開發者註冊一個提示符號而非完整的工具。對於此類工作流程，其主要操作是接收單一輸入（轉錄文字 URI）並產生單一不可鍊式輸出（例如，節目筆記、部落格文章、社群媒體更新），配置好的提示符號似乎是理想的解決方案。鑑於這些工具已經整合了 AI 模型，因此利用該 AI 來產生所需的內容也就順理成章了。

然而，播客助手的主要目標不僅限於內容生成，還包括將內容長期保存到儲存桶中。提示功能旨在將生成的文字直接輸出給用戶，通常是透過 Gemini CLI。對於此伺服器，產生的文字必須儲存到 Google Cloud Storage (GCS) 儲存桶中，以便在後續步驟中使用或方便其他主持人下載。因此，儘管功能更複雜，我還是選擇實現完整的工具，因為它們提供了對輸出儲存的明確控制，並能保存 GCS URI 以供工作流程的下一步使用。

透過 Cloud Run 進行身份驗證以確保安全

能夠與我的合作主機共享這個 MCP 伺服器，這讓它成為一個很棒的解決方案——但我不想讓全世界的人都來使用它！因此，我希望保持最初程式碼實驗室「如何在 Cloud Run 上部署安全的MCP 伺服器」的精神，並要求使用者在使用我的 MCP 伺服器時進行身份驗證。

雖然可以在 MCP 伺服器層級設定身份驗證，但我比較懶，而且那聽起來像是要寫更多程式碼，所以我希望利用 Cloud Run 層級的身份驗證，我透過使用 gcloud cli 標誌「--no-allow-unauthenticated」進行部署實現了這一點。

在程式碼實驗室中，身份驗證基本上是按會話處理的，最終用戶需要配置一個一小時後過期的 ID 令牌。這對於我的播客使用場景來說也足夠了，因為我可以將 ID 令牌的建立加入到我們的發布工作流程中，而且實際使用伺服器工具應該只需要幾分鐘。但我也想探索一些更適合我有限數量的目標用戶的方案。

在我的 podcast-assistant-mcp 伺服器的 README 檔案中，我概述了三種不同的驗證選項：

• 方案一：使用 Gemini CLI 的身份驗證令牌：此方法設定快捷，適用於臨時存取 MCP 伺服器。令牌有效期為一小時。

• 方案二：使用 Gemini CLI 的代理：此方法更加穩定可靠，建議用於持續開發。代理程式會自動處理身份驗證並將請求轉送到 MCP 伺服器。

• 【範例】選項 3：使用服務帳戶：選項 1 和 2 均涉及透過 Gemini CLI 以使用者身分進行驗證。此方法涉及透過服務帳戶以服務或代理程式（而非使用者）身分進行身份驗證。本專案不包含此類服務或代理，因此此選項僅作為範例提供，部署本專案後無法立即使用。

就我的使用場景而言，方案一或方案二都可以。我可能會和我的合作主機商一起測試一下，看看他們更喜歡哪一個。隨著我們不斷擴展MCP伺服器的功能，我們的偏好和需求也可能會改變。

結論：行之有效的工作流程

雖然我仍然渴望建立一個完全整合、全面的解決方案，但這個 MCP 伺服器是一個實用的工具，它能夠正常工作，融入我們團隊的日常工作流程，並且具有可擴展性，允許我和我的共同主持人根據需要加入更多功能，從而使每個人都受益。

在過去的幾個月裡，這個專案一直為我節省大量時間。現在，我的其他主持人可以直接透過 Gemini CLI 使用它，大家共同節省了寶貴的時間，可以投入到未來節目的製作中。你可以在這個 GitHub 倉庫中找到這個 MCP 伺服器的簡潔實作（只需三個檔案），並開始建立你自己的實用省時的 MCP 伺服器！

原文出處：https://dev.to/googleai/how-i-made-an-mcp-server-that-saves-me-an-hour-per-week-3k8k