Abstract

Are you tired of the repetitive process of publishing your Astro blog? Switching directories, running Git commands, building the site, and deploying to GitHub Pages—it’s a tedious workflow. This article introduces MCP-Blog, an automation tool I developed to consolidate all these steps into a single command, dramatically boosting your productivity. We’ll dive into the “Model-Context Protocol” (MCP) design philosophy behind it, how it manages cross-directory permissions, Git automation, and its seamless integration with Astro and GitHub Pages.

1. Background and Motivation: Why MCP-Blog?

As a tech blogger, I use the excellent static site generator Astro for my personal blog, which is hosted on GitHub Pages. While the development experience with Astro is fantastic, my publishing workflow was filled with repetitive tasks:

  1. After writing a new post in my blog project geyuxu.com
  2. Run git add ., git commit -m "...", and git push to push the source code to the main branch
  3. Execute npm run build to generate static files in the dist directory
  4. Push the contents of the dist directory to the gh-pages branch for deployment

This process not only involves multiple commands but is also prone to issues, especially if the dist directory isn’t managed correctly by Git. More importantly, I wanted a central “management hub” to handle tasks like this, rather than cluttering my project directories with various scripts.

This led me to create the MCP-Blog project. Its core goal is to: Automate the entire commit-and-deploy workflow for one project directory from a completely separate, dedicated management directory, using a single command.

This approach solves two major pain points:

  1. Operational Isolation: Separates management scripts from blog content, keeping the blog repository clean and focused
  2. Process Automation: Simplifies a multi-step process into a single action, reducing human error and increasing efficiency

2. Technical Architecture: The MCP Design Philosophy

What is MCP (Model Context Protocol)?

The “Model-Context Protocol” (MCP) is not a public network protocol, but rather a command-line interaction specification I designed for this project. Its core philosophy is:

Enable an independent execution script (Model) to understand and operate on a target project within a specific context (Context).

In this project:

  • Model: Our mcp-blog project, which acts as the active executor
  • Context: Our geyuxu.com blog project, which is the target being operated on
  • Protocol: The command-line interface and script execution logic we define. For example, ./mcp.sh "commit message" is an implementation of this protocol

Architecture Diagram

The workflow is straightforward:

+-----------+       +-------------------------+       +---------------------+       +----------------+
|           |       |                         |       |                     |       |                |
|   User    |------>|  MCP Script (mcp.sh)    |------>|  Astro Blog Project |------>|  GitHub Repo   |
|           |       |                         |       | (geyuxu.com)        |       | (main/gh-pages)|
+-----------+       +-------------------------+       +---------------------+       +----------------+
      |                        |                                |                           |
      | 1. Provide commit msg  | 2. cd to blog directory       | 3. Git ops & build       | 4. Deploy to Pages
      |                        | 4. Execute deploy commands     |                           |

The key is how the MCP script effectively “traverses” into the Astro blog project directory to execute operations.

3. Implementation Details: Building the Automation Tool

Let’s examine the core implementation. The entire project is driven by a single Shell script.

Project Structure:

/Users/geyuxu/repo/blog/
├── mcp-blog/         # MCP project
│   └── mcp.sh
└── geyuxu.com/       # Astro blog project
    ├── src/
    ├── public/
    ├── package.json
    └── ...

1. Core Script mcp.sh

This is the heart of our automation. It handles parameter reception, directory switching, command execution, and error handling.

#!/bin/bash

# Exit immediately on error
set -e

# --- Configuration ---
# Define MCP project path (where the script resides)
MCP_PROJECT_PATH="/Users/geyuxu/repo/blog/mcp-blog"
# Define blog repository path (target to operate on)
BLOG_REPO_PATH="/Users/geyuxu/repo/blog/geyuxu.com"
# --- End Configuration ---

# 1. Check input parameters: commit message is required
if [ -z "$1" ]; then
  echo "❌ Error: Please provide a commit message."
  echo "Usage: ./mcp.sh \"your commit message\""
  exit 1
fi

COMMIT_MESSAGE=$1

echo "🚀 MCP-Blog task starting..."
echo "================================="

# 2. Cross-directory permission management core
echo "📂 Entering blog repository: $BLOG_REPO_PATH"
cd "$BLOG_REPO_PATH"

# 3. Git automation: commit source code
echo "🔄 Syncing source code to main branch..."
git add .
git commit -m "$COMMIT_MESSAGE"
git push origin main

echo "✅ Source sync complete."
echo "================================="

# 4. Astro blog system integration: build project
echo "🛠️  Building Astro project..."
npm run build

echo "✅ Build complete."
echo "================================="

# 5. GitHub Pages deployment
echo "🚀 Deploying to GitHub Pages..."
# We use the gh-pages package to simplify deployment
# It automatically pushes dist directory contents to gh-pages branch
npm run deploy

echo "✅ Deployment successful!"
echo "================================="
echo "🎉 All tasks completed, blog updated!"

# Return to original directory (optional, good practice)
cd "$MCP_PROJECT_PATH"

2. Key Technical Points

  • Cross-directory Permission Management (cd "$BLOG_REPO_PATH"): This seemingly simple cd command is key to cross-directory operations. After the script starts, it first switches the current working directory to the blog project. This way, all subsequent git and npm commands execute as if they were run directly in the geyuxu.com directory, naturally gaining the “context permissions” to operate on that directory’s files.

  • Git Automation (git add/commit/push): The script handles source code commits using standard Git commands. Passing the commit message as the script’s first parameter ($1) adds flexibility.

  • Astro Integration (npm run build): Every Astro project has a build script defined in package.json. Our automation script calls it directly without concerning itself with the complex internal build process, achieving perfect decoupling.

  • GitHub Pages Deployment (npm run deploy): To simplify deployment, I highly recommend using the gh-pages npm package.

    First, install it in your Astro project (geyuxu.com):

    npm install gh-pages --save-dev

    Then, add a deploy command to your geyuxu.com/package.json scripts:

    {
      "scripts": {
        "dev": "astro dev",
        "start": "astro dev",
        "build": "astro build",
        "preview": "astro preview",
        "astro": "astro",
        "deploy": "gh-pages -d dist" 
      }
    }

    The gh-pages -d dist command automatically pushes the dist directory contents to the gh-pages branch.

4. Usage Example: Running MCP-Blog

Assuming you’ve completed the above configuration, publishing a new blog post is now as simple as breathing.

  1. Grant execution permissions to the script (only needed once):

    cd /Users/geyuxu/repo/blog/mcp-blog
    chmod +x mcp.sh
  2. One-command publishing: After finishing your writing in geyuxu.com, open the terminal and run:

    ./mcp.sh "feat: add new article about MCP-Blog"

Then, grab a coffee and watch the terminal automate everything:

🚀 MCP-Blog task starting...
=================================
📂 Entering blog repository: /Users/geyuxu/repo/blog/geyuxu.com
🔄 Syncing source code to main branch...
[main 1234567] feat: add new article about MCP-Blog
 1 file changed, 1 insertion(+)
 ...
✅ Source sync complete.
=================================
🛠️  Building Astro project...
> [email protected] build
> astro build
...
✅ Build complete.
=================================
🚀 Deploying to GitHub Pages...
> [email protected] deploy
> gh-pages -d dist
Published
✅ Deployment successful!
=================================
🎉 All tasks completed, blog updated!

A few minutes later, your new article will be live online.

5. Summary and Future Directions

The MCP-Blog project successfully automates the complex blog publishing workflow through a simple Shell script, achieving:

  • Efficiency Boost: Reduces 5-6 steps to a single command
  • Error Reduction: Automated operations prevent manual omissions or mistakes
  • Clean Code: Separates management logic from business logic (blog content)

Future exploration directions:

  1. Feature Enhancement: Add a command to create new articles, e.g., ./mcp.sh new "Article Title", which automatically generates a Markdown template with frontmatter
  2. Platform Upgrade: Upgrade from Shell script to a more robust Node.js or Python CLI tool with richer interaction and error handling
  3. CI/CD Integration: While local scripts are convenient, the ultimate automation solution is migrating to GitHub Actions. When the main branch receives new pushes, it automatically triggers the build and deployment workflow

I hope this small project inspires you. Automation is second nature to us engineers—by delegating repetitive work to machines, we can focus on creating more valuable content.

Ge Yuxu • AI & Engineering

脱敏说明:本文所有出现的表名、字段名、接口地址、变量名、IP地址及示例数据等均非真实,仅用于阐述技术思路与实现步骤,示例代码亦非公司真实代码。示例方案亦非公司真实完整方案,仅为本人记忆总结,用于技术学习探讨。
    • 文中所示任何标识符并不对应实际生产环境中的名称或编号。
    • 示例 SQL、脚本、代码及数据等均为演示用途,不含真实业务数据,也不具备直接运行或复现的完整上下文。
    • 读者若需在实际项目中参考本文方案,请结合自身业务场景及数据安全规范,使用符合内部命名和权限控制的配置。

Data Desensitization Notice: All table names, field names, API endpoints, variable names, IP addresses, and sample data appearing in this article are fictitious and intended solely to illustrate technical concepts and implementation steps. The sample code is not actual company code. The proposed solutions are not complete or actual company solutions but are summarized from the author's memory for technical learning and discussion.
    • Any identifiers shown in the text do not correspond to names or numbers in any actual production environment.
    • Sample SQL, scripts, code, and data are for demonstration purposes only, do not contain real business data, and lack the full context required for direct execution or reproduction.
    • Readers who wish to reference the solutions in this article for actual projects should adapt them to their own business scenarios and data security standards, using configurations that comply with internal naming and access control policies.

版权声明:本文版权归原作者所有,未经作者事先书面许可,任何单位或个人不得以任何方式复制、转载、摘编或用于商业用途。
    • 若需非商业性引用或转载本文内容,请务必注明出处并保持内容完整。
    • 对因商业使用、篡改或不当引用本文内容所产生的法律纠纷,作者保留追究法律责任的权利。

Copyright Notice: The copyright of this article belongs to the original author. Without prior written permission from the author, no entity or individual may copy, reproduce, excerpt, or use it for commercial purposes in any way.
    • For non-commercial citation or reproduction of this content, attribution must be given, and the integrity of the content must be maintained.
    • The author reserves the right to pursue legal action against any legal disputes arising from the commercial use, alteration, or improper citation of this article's content.

Copyright © 1989–Present Ge Yuxu. All Rights Reserved.