Skip to main content
Glama
deenesjakoruzh
MasatoshiSano

mcp-blog

by MasatoshiSano
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

mcp-blog

Claude Code / Cursor から自然言語でブログ記事を投稿できる MCP サーバーです。

できること

自分のプロジェクトで作業しながら、Claude に話しかけるだけでブログに投稿できます。

「今日のデバッグ作業をブログ記事にして投稿して」
「記事の一覧を見せて」
「slug が xxx の記事を削除して」

Related MCP server: substack-mcp

仕組み

あなた（Claude Code / Cursor）
  ↓ 自然言語で指示
MCP サーバー（このパッケージ）
  ↓ HTTPS
ブログ API（Lambda）
  ↓
S3 に保存 → GitHub Actions が起動 → サイト自動更新（1〜3分）

セットアップ

必要なもの

  • Node.js v20 以上

  • ブログ API キー（管理者から発行）

設定ファイルに追加

Claude Code (~/.claude/settings.json) または Cursor (~/.cursor/mcp.json) に追記します。

{
  "mcpServers": {
    "blog": {
      "command": "npx",
      "args": ["-y", "github:MasatoshiSano/mcp-blog"],
      "env": {
        "BLOG_API_ENDPOINT": "https://dxbqlfvrescw1.cloudfront.net/api",
        "BLOG_API_KEY": "your-api-key"
      }
    }
  }
}

設定後は Claude Code / Cursor を再起動すると使えるようになります。

ツール一覧

ツール

説明

blog_preview_post

markdown を渡すと AI がフロントマターを自動補完・本文を校正してプレビューを返す

blog_publish_post

記事を S3 に保存して GitHub Actions のビルドをトリガーする

blog_list_posts

記事一覧を取得する（公開済み・下書きでフィルタ可能）

blog_get_post

指定 slug の記事 Markdown を取得する

blog_delete_post

記事を削除してビルドをトリガーする

環境変数

変数名

必須

説明

BLOG_API_ENDPOINT

✅

ブログ API のベース URL（例: https://xxx.cloudfront.net/api）

BLOG_API_KEY

✅

認証用 API キー

開発者向け: ローカルビルド

cd mcp-blog
npm install
npm run build
# → dist/index.js が生成される

ローカルビルドを使う場合は npx の代わりに直接 node で指定します：

{
  "mcpServers": {
    "blog": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-blog/dist/index.js"],
      "env": { ... }
    }
  }
}

Available Tools

5 tools
blog_delete_postA

指定したスラグの記事を S3 から削除し、GitHub Actions ビルドを発火させる。

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesSlug of the post to delete

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses two key behaviors: deletion from S3 and triggering a GitHub Actions build. However, it doesn't mention irreversibility, error handling for missing slugs, or details about the build triggered. Lacks full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core action and side effect without any extraneous words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, lack of output schema, and presence of sibling blog tools, the description provides sufficient context about what the tool does. It could mention that the deletion is permanent, but overall it is complete enough for a straightforward delete operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the 'slug' parameter. The description adds no per-parameter details beyond what the schema provides, so it meets the baseline without additional value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool deletes a blog post by its slug from S3 and triggers a GitHub Actions build. This distinguishes it from sibling tools like blog_get_post (retrieval) and blog_publish_post (creation/publishing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool vs. alternatives, such as when to delete versus unpublish or archive. No context about prerequisites or side effects beyond the bare action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

blog_get_postA

指定したスラグの記事を S3 から読み出し、Markdown 本体と frontmatter を返す。編集ワークフロー (取得→修正→blog_publish_post で上書き) で使う。

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesSlug of the post to fetch

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the source (S3), that it's a read operation with no side effects, and the return content. Could be more explicit about error handling or missing slugs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey action, resource, and workflow context. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read tool: describes purpose, source, return content, and usage pattern. Without output schema, could detail return structure more, but 'Markdown body and frontmatter' provides sufficient guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the single parameter with a description. The description repeats the concept of 'specified slug' without adding new semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (read article from S3), what it returns (Markdown body and frontmatter), and its role in the edit workflow, distinguishing it from siblings like blog_list_posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the tool is part of an edit workflow (fetch->modify->overwrite), giving clear usage context. However, it does not explicitly mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

blog_list_postsB

ブログ記事の一覧を取得する。published フィルタと件数上限を指定可能。

ParametersJSON Schema
NameRequiredDescriptionDefault
publishedNo
limitNo

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It implies a read operation but does not explicitly confirm non-destructiveness, auth requirements, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences convey the purpose and key parameters with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with 2 parameters, no output schema, and no annotations, the description is too sparse. It lacks defaults, pagination info, and ordering, leaving the agent underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions 'published filter and count limit' but adds no value beyond the parameter names, failing to explain types or behavior when omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a list of blog posts, which distinguishes it from sibling tools that delete, get single, preview, or publish posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions optional filters but does not provide any guidance on when to use this tool versus alternatives, leaving the agent to infer from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

blog_preview_postA

AI によるフロントマター補完・本文構造補正を実行してプレビュー結果を返す。publish 前に必ず呼ぶこと。

ParametersJSON Schema
NameRequiredDescriptionDefault
markdownYesMarkdown content of the post (including frontmatter)
slugNo
imageMetaNo

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states AI corrections and preview return, but does not disclose side effects (e.g., persistence, data modification, latency, or cost) beyond basic behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action and concluded with a direct usage instruction. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with AI processing, a nested parameter (imageMeta), and no output schema, the description does not explain the purpose of slug and imageMeta, nor what the preview output contains. Essential invocation details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one of three parameters (markdown) has a schema description. The description does not add any additional meaning for slug or imageMeta. With 33% schema coverage, the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it performs AI-driven frontmatter completion and body structure correction to return a preview. It distinguishes itself from the sibling publish tool by specifying it must be called before publishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'must call before publish,' providing clear context for when to use. However, it does not describe when not to use or mention alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

blog_publish_postB

AI 補正済みの markdown と frontmatter を S3 に保存し、GitHub Actions ビルドを発火させて公開する。

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesURL slug for the post (alphanumeric, hyphens, underscores)
markdownYesFinalized Markdown content (after preview correction)
frontmatterYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description mentions side effects (S3 save, build trigger) but lacks details on mutability, overwrite behavior, prerequisites (e.g., slug uniqueness), or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise, and front-loaded with the core action. However, it could be structured with separate clauses for storage and trigger.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a 3-parameter tool, the description is incomplete. It omits return value, success/failure indicators, concurrency considerations, and any post-conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers parameters with reasonable descriptions; 'slug' and 'markdown' are well explained. The description adds context that the markdown is 'AI corrected', but does not add significant semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: saving AI-corrected markdown and frontmatter to S3 and triggering a GitHub Actions build for publication. It differentiates from sibling tools (delete, get, list, preview) by focusing on the publish workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., preview vs. publish). The description only explains what it does, not when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct action: delete, get, list, preview, and publish. No overlaps in purpose.

Naming Consistency5/5

All tools follow the consistent blog_verb_noun pattern with snake_case (e.g., blog_delete_post, blog_list_posts).

Tool Count5/5

Five tools are appropriately scoped for a blog server, covering essential operations without being too few or too many.

Completeness5/5

The set covers the full lifecycle: list, get, preview, publish, and delete. No obvious missing operations for a simple blog workflow.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MasatoshiSano/mcp-blog'

If you have feedback or need assistance with the MCP directory API, please join our Discord server