Vibe Coding ContentMCP

Published 7 Jun 2026

How I built ContentMCP, a scoped MCP for content repositories that lets AI tools create and edit Markdown files without giving them access to an entire codebase.

Last week I built an MCP server for my personal blog.

It worked well, but it was very specific to one site.

That got me thinking about a broader idea: what if you could create a scoped MCP for any content repository?

That is the idea behind ContentMCP.

Not full repository access. Not a traditional CMS.

Just a carefully controlled interface that lets AI tools work with content and nothing else.

Content Repos Already Have a Workflow

Many developer-owned sites do not need another publishing platform.

The content already lives in GitHub. Deployments already happen through Netlify, Cloudflare, Vercel, or GitHub Actions. Pull requests already provide review workflows and previews.

The real friction is not publishing.

It is all the small mechanical steps around creating and editing content:

  • finding the correct folder
  • remembering naming conventions
  • copying frontmatter
  • creating commits
  • opening pull requests

None of it is difficult. It is just repetitive.

I wanted to see what happened if those steps became conversational.

Instead of navigating a repository, you could simply ask:

Create a new article about MCP security best practices.

The assistant handles the mechanics while the repository remains the source of truth.

A Scoped MCP

The key idea is scope.

When people hear "AI with repository access" they often imagine giving a model access to an entire codebase.

That is not what ContentMCP does.

A workspace defines exactly which paths an assistant can access.

For example:

Allowed:
content/topics/**

Denied:
.env*
package.json
wrangler.jsonc

The assistant can list, read, create, and edit files inside the content folder, but it cannot touch application code, dependencies, configuration files, or secrets.

That feels like a much safer model.

The AI gets access to the content it needs, while everything else stays outside the boundary.

How It Works

After connecting a GitHub repository through a GitHub App, ContentMCP exposes a small set of tools:

repo.list_files
repo.read_file
repo.create_file
repo.edit_file
repo.open_pull_request

Those tools can then be used from ChatGPT, Claude, Codex, or any MCP-compatible client.

The result is a workflow that feels surprisingly natural:

Read the last few posts and create a draft covering scoped MCP servers.

Or:

Update this article to include a section on direct commits.

The assistant performs the file operations while GitHub continues handling version control and history.

Pull Requests or Direct Commits

By default, ContentMCP follows the safer workflow.

Changes are committed to a branch and a pull request is opened for review.

AI creates content
↓
Pull request opens
↓
Preview deploy runs
↓
Review and merge

For many teams, that is the right balance between speed and control.

I also added an optional direct commit mode.

In that setup, the assistant can commit straight to the default branch.

For personal blogs, documentation sites, and internal projects, that can feel surprisingly close to a lightweight CMS:

Create a new post about ContentMCP.

A few seconds later the file exists, the commit is pushed, and the site deploys automatically.

Useful and risky tend to arrive together, so direct commits are disabled by default.

Mostly Vibe Coded

The other interesting part of the project is how it was built.

ContentMCP was largely vibe coded using GPT 5.5 and Codex.

I did not start with a detailed specification. I started with a simple idea:

I want users to create scoped MCP servers for content repositories.

From there, the application evolved through conversation.

GitHub OAuth, GitHub App installation, workspace membership, repo configuration, allowed and denied paths, MCP OAuth, pull request creation, direct commit support, and a small debug UI were all built incrementally.

The AI generated a lot of code, but the important decisions remained human:

  • what the product should do
  • where the safety boundaries should be
  • which defaults are sensible
  • what trade-offs are acceptable

That is the part of vibe coding I find most compelling.

It is not about removing the developer.

It is about making it easier to explore a product idea while the implementation keeps pace.

Why MCP Fits So Well

MCP is a natural fit for this kind of workflow.

Without MCP, an assistant can help write content.

With MCP, it can actually perform the work.

It can read existing articles, create new files, update drafts, and open pull requests.

The important detail is that the application still controls the boundaries.

The assistant can only do what the tools allow.

That is a pattern I keep coming back to with MCP:

AI becomes more capable, but the product defines the constraints.

Looking Ahead

ContentMCP is still early, but there are plenty of directions it could go.

Things I would like to explore include:

  • framework-specific content presets
  • frontmatter templates
  • multiple scoped MCPs per repository
  • preview deployment awareness
  • stronger safety controls around direct commits

The goal is not to become another CMS.

The goal is to make repositories feel easier to work with using AI.

Final Thoughts

What I like most about ContentMCP is its simplicity.

Git remains the source of truth.

GitHub remains the workflow.

Deployments remain unchanged.

The MCP simply provides a safe interface between an AI assistant and a content repository.

In many ways, the project ended up being a perfect loop.

I used AI to build a tool that gives AI a controlled way to edit content.

That feels like a small glimpse of where developer tooling is heading.