Draft-Only Blogger MCP

• 

  Draft-Only Blogger MCP — bounded AI automation that creates and independently verifies drafts while keeping publishing authority unavailable

Inspiration

I wanted to explore a simple question: how can an AI agent be useful without silently inheriting more authority than it needs?

Publishing systems are a good test case. An AI assistant may be capable of creating content, but that does not mean it should automatically be allowed to publish, update, or delete it.

That led to Draft-Only Blogger MCP: a deliberately narrow MCP server that lets an AI-assisted workflow create Blogger drafts and verify them, while structurally excluding publication authority.

What it does

The server exposes exactly two MCP tools:

• create_draft — creates a draft in one configured Blogger blog.
• inspect_draft — reads the draft back and independently verifies the expected result.

There is no MCP tool for publishing, updating, deleting, scheduling, or general Blogger administration.

The verification step checks six things:

• target blog
• draft status
• title
• canonical body
• labels
• provenance

The goal is not just to perform an action, but to produce evidence that the intended action actually happened.

How I built it

The project is a local Node.js and TypeScript MCP server using the Model Context Protocol SDK, Google Blogger API v3, OAuth user credentials, Zod validation, and deterministic verification logic.

The create flow is intentionally bounded:

1. Validate the request.
2. Make at most one Blogger draft creation attempt.
3. Record provenance locally.
4. Read the post back through the Blogger ADMIN view.
5. Compare the remote result with the expected projection.
6. Return a verification result.

A local owner-controlled sidecar stores provenance, while Blogger remains the source of truth for the actual post state.

Challenges

The biggest challenge appeared during live testing.

My original design attempted to carry provenance through Blogger customMetaData. The API accepted the request, but the metadata did not reliably round-trip through the readback surface.

Instead of weakening verification, I changed the smallest affected boundary: provenance moved into a strict local sidecar, while Blogger continued to represent the visible post state.

Another important challenge was handling uncertain remote effects. If a create request times out or its result cannot be established, blindly retrying could create duplicate drafts. The server therefore treats an unknown remote effect as unsafe to retry automatically.

What I learned

The main lesson was that the effect path and the proof path should be designed together.

It is not enough for an AI tool to say that an action succeeded. A useful agent workflow also needs an independent way to verify what happened.

I also learned to separate several concepts that are easy to collapse:

• capability is not authority
• execution is not verification
• a generated result is not automatically an accepted result
• failure to prove an effect should not create permission to retry it blindly

The result is intentionally small, but that is the point: a useful AI integration can remain powerful while keeping its authority explicit, bounded, and independently verifiable.

Built With

• agentic
• agents
• ai
• api
• apis
• blogger
• context
• developer
• google
• governance
• human-in-the-loop
• integration
• local-first
• mcp
• model
• node.js
• oauth
• protocol
• provenance
• safety
• tools
• typescript
• verification
• vitest
• zod