Skip to main content
Glama
h-kazuki-pixel

release-announcer-mcp

by h-kazuki-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

release-announcer-mcp

CI

An MCP server that turns a GitHub repository into ready-to-review release announcements — and checks that the repo is actually ready to ship.

Point it at any public repo and ask Claude for an "announcement kit". You get drafts for:

  • X/Twitter post (short, link included, in two languages)

  • Reddit post (understated "I built a thing" tone — draft only, never auto-posted)

  • GitHub profile README table row

  • awesome-list entry + pull request text

  • MCP directory listing (short/long description + tags)

Plus a publish-readiness checklist: LICENSE, README quality, Release, Topics, About description, .gitignore — each with a concrete fix suggestion when missing.

No API key required. Works with any public GitHub repository.

Why

If you ship open-source tools on a regular cadence, the release itself is the easy part. The repetitive part is everything after: writing the announcement, adapting it per platform, updating your profile, submitting to directories. This server gathers the facts (README, release notes, metadata) and hands your LLM a strict writing brief, so every announcement is accurate, consistent, and takes minutes instead of an hour.

By design, this tool generates drafts only. It never posts anywhere. You review, then you post.

Related MCP server: codeglance-mcp

Tools

Tool

What it does

fetch_repo_info

Fetch repo metadata, latest release, README, and root files

check_publish_readiness

Run the pre-publication checklist (pass/warn/fail with fixes)

build_announcement_brief

Build a complete writing brief for any subset of announcement targets

Setup

Requires Node.js 18+.

git clone https://github.com/h-kazuki-pixel/release-announcer-mcp.git
cd release-announcer-mcp
npm install
npm run build

Add to your Claude Desktop config (claude_desktop_config.json):

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

claude_desktop_config.json is at:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

GitHub API rate limit

Unauthenticated GitHub API requests are capped at 60 per hour per IP address, and building one announcement kit makes several of them. A token raises the cap to 5,000 per hour.

Put the token in the env block of the config file. Do not export it in your shell — Claude Desktop starts MCP servers without inheriting the shell environment, so an exported variable never reaches this server.

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

The token needs no scopes. This server only reads public repositories.

Docker (optional)

The repository ships a Dockerfile (Node 20 slim, multi-stage build) for running the server in a container. The Claude Desktop setup above does not need it.

docker build -t release-announcer-mcp .

Usage

Just ask Claude, for example:

"Build the announcement kit for h-kazuki-pixel/jp-dates-mcp-server"

"Is my-org/my-repo ready to publish? Run the checklist."

"Draft only the X post and the awesome-list entry for owner/repo."

Example output (checklist)

# Publish readiness: owner/repo

**6/8 checks passed**

- ✅ LICENSE file — MIT License detected.
- ✅ README — README found.
- ⚠️ README: setup instructions — No obvious setup section. Add installation steps.
- ✅ README: usage examples — Usage/example content detected.
- ❌ GitHub Release — No release found. Create one: Releases → 'Draft a new release' → tag v1.0.0.
- ✅ Topics (discovery tags) — 4 topics set.
- ✅ About description — Description set.
- ✅ .gitignore — .gitignore found.

Development

npm run build   # compile TypeScript
npm test        # run integration tests (uses a local mock of the GitHub API)

License

MIT

日本語

GitHubリポジトリを指定するだけで、リリース告知に必要な文章一式のドラフトと、公開前チェックリストを生成するMCPサーバーです。

できること

  • X(Twitter)告知文(2言語・リンク付き・短文)

  • Reddit投稿の下書き(宣伝色を抑えた文体。自動投稿は一切しません)

  • GitHubプロフィールREADMEの作品表の行

  • awesomeリスト登録用のエントリ+PR文

  • MCPディレクトリ(mcp.so等)登録用の説明文+タグ案

  • 公開前チェックリスト: LICENSE / READMEの充実度 / Release作成 / Topics / About欄 / .gitignore を自動判定し、不足があれば直し方を提示

APIキー不要。公開リポジトリならどれでも使えます。

セットアップ

Node.js 18以上が必要です。

git clone https://github.com/h-kazuki-pixel/release-announcer-mcp.git
cd release-announcer-mcp
npm install
npm run build

Claude Desktopの設定ファイル(claude_desktop_config.json)に追加:

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

claude_desktop_config.json の場所:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

GitHub APIのレート上限

未認証のGitHub APIはIPアドレスあたり1時間60リクエストに制限されており、告知セットを1回作るだけで複数回叩きます。トークンを設定すると1時間5,000リクエストに上がります。

トークンは設定ファイルの env ブロックに書いてください。シェルで export しても届きません。 Claude Desktop はMCPサーバーを、シェルの環境変数を引き継がない形で起動するためです。

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

トークンに権限(スコープ)の付与は不要です。このサーバーは公開リポジトリの読み取りしか行いません。

Docker(任意)

このリポジトリには Dockerfile(Node 20 slim・マルチステージ構成)が同梱されています。コンテナで動かしたい場合に使います。上のClaude Desktopの手順では不要です。

docker build -t release-announcer-mcp .

使い方

Claudeにこう頼むだけです:

「h-kazuki-pixel/jp-dates-mcp-server の告知セットを作って」

「owner/repo は公開準備できてる?チェックリストを実行して」

設計方針

このツールが生成するのは下書きのみです。SNSへの自動投稿機能は意図的に持たせていません。最終確認と投稿は必ず人間が行います。

ライセンス

MIT

Available Tools

3 tools
build_announcement_briefBuild announcement briefA
Read-onlyIdempotent

Gather a repository's facts (README, latest release notes, metadata) and return a complete writing brief: source material plus strict per-target writing instructions. The calling LLM then writes the final draft texts from this brief.

Targets available:

  • x_post: X/Twitter announcement (Japanese + English, ~160 chars)

  • reddit_draft: understated Reddit post draft (English, title + body)

  • profile_readme_row: GitHub profile README table row

  • awesome_mcp_pr: awesome-mcp list entry + PR title/body

  • directory_listing: MCP directory (mcp.so etc.) descriptions + tags

Args:

  • owner (string): GitHub user/org name

  • repo (string): repository name

  • targets (string[], optional): subset of targets; defaults to all five

Returns: a Markdown brief. After calling this tool, write the requested draft texts following the brief's rules exactly. All output is draft-only for human review — never post anywhere automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesRepository name, e.g. 'jp-dates-mcp-server'
ownerYesGitHub user or organization name, e.g. 'h-kazuki-pixel'
targetsNoWhich announcement targets to include (default: all)

TDQS

A4.6/5.0
Behavior5/5

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds that it returns a Markdown brief with source material and per-target instructions, emphasizes it never posts automatically, and describes the gathering process (README, releases, metadata). No contradictions with annotations.

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 well-structured: purpose paragraph, target list with descriptions, argument list, and return/usage note. Every sentence is necessary and front-loaded. No repetition or verbosity.

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?

The tool is complex with five targets and multiple data sources. The description provides a good overview and step-by-step instructions, but lacks details on the exact structure of the returned Markdown brief. However, given the annotations and schema richness, it is mostly complete for an AI agent without an output schema.

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

Parameters4/5

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

Schema coverage is 100% with descriptions for owner, repo, and targets. The description restates these briefly but adds useful context: targets can be a subset with a default of all five. It also gives the enum values inline. This adds slight value beyond the schema, justifying a score above baseline 3.

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 it gathers repository facts and returns a writing brief with per-target instructions. The verb 'build' and resource 'announcement_brief' are specific. It distinguishes from siblings fetch_repo_info (which just fetches info) and check_publish_readiness (which checks readiness), making the purpose unambiguous.

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?

The description explains the workflow: call this tool to get a brief, then write drafts following its instructions, and notes that output is draft-only for human review, never auto-posted. It lists available targets but does not explicitly contrast with sibling tools or state when not to use it. However, the context is clear enough for the AI agent.

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

check_publish_readinessCheck publish readinessA
Read-onlyIdempotent

Run a pre-publication checklist against a public GitHub repository and report pass/warn/fail per item.

Checks: LICENSE present (MIT expected), README present with setup instructions and usage examples, GitHub Release created, 3+ Topics set, About description set, .gitignore present.

Args:

  • owner (string): GitHub user/org name

  • repo (string): repository name

Returns: a Markdown checklist report plus structured JSON ({ repo, passed, total, items: [{id, label, status, detail}] }). Each failing item includes a concrete fix suggestion.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesRepository name, e.g. 'jp-dates-mcp-server'
ownerYesGitHub user or organization name, e.g. 'h-kazuki-pixel'

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by specifying the tool operates on a public repo, returns a structured checklist report with fix suggestions, and confirms no mutation. No contradictions.

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 well-structured with bullet points for checks, clear argument listing, and explicit return format. Every sentence is informative and necessary, with no redundancy.

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

Completeness5/5

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

Despite no output schema, the description fully details the return format (Markdown checklist plus structured JSON with item details). Combined with annotations and schema, the definition is complete for agent usage.

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?

Parameter descriptions in the input schema are already detailed (maxLength, minLength, and descriptions). The description's 'Args' section repeats this information without adding deeper semantics, so baseline 3 is appropriate.

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 it runs a pre-publication checklist against a public GitHub repository, listing specific checks. It distinctly separates from sibling tools like fetch_repo_info and build_announcement_brief.

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?

The description explicitly states the use case (pre-publication readiness check) and lists what checks are performed. However, it does not specify when to avoid using this tool or provide direct alternatives beyond sibling context.

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

fetch_repo_infoFetch repository infoA
Read-onlyIdempotent

Fetch public information about a GitHub repository: description, topics, license, stars, latest release (tag + notes), README content, and root file list.

Use this when you need raw facts about a repository before writing about it or checking it.

Args:

  • owner (string): GitHub user/org name

  • repo (string): repository name

Returns: structured JSON with repo metadata, latestRelease (or null), readme text (truncated at 12000 chars), and rootFiles.

Errors: returns a clear message for unknown repos (404) and API rate limits (retry later or set GITHUB_TOKEN env var).

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesRepository name, e.g. 'jp-dates-mcp-server'
ownerYesGitHub user or organization name, e.g. 'h-kazuki-pixel'

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. The description adds behavioral details beyond these: returns structured JSON, error handling for 404 and rate limits, and README truncation at 12000 chars. No contradiction with annotations.

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?

The description is well-structured with sections: what it fetches, when to use, Args, Returns, Errors. It is front-loaded with key information. Slightly verbose but every part adds value; could be more concise but still effective.

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 no output schema, the description explains return structure and error messages. Annotations cover safety, so the description completes the picture for a tool of moderate complexity. It lacks explicit details on exact fields of repo metadata, but overall is sufficient.

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% with clear parameter descriptions. The description repeats parameter names and types but adds little beyond what the schema provides. It does not add nuances like format or validation rules. Baseline of 3 for high coverage is appropriate.

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 verb 'Fetch' and the specific resource 'public information about a GitHub repository'. It enumerates the fetched data (description, topics, license, stars, latest release, README content, root file list), distinguishing it from siblings like check_publish_readiness and build_announcement_brief, which have different purposes.

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?

The description provides explicit usage context: 'Use this when you need raw facts about a repository before writing about it or checking it.' While it doesn't explicitly state when not to use or mention alternatives, the context is clear and sufficient for the agent to decide.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedbuild_announcement_brief
    • First observedcheck_publish_readiness
    • First observedfetch_repo_info
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: fetch_repo_info retrieves raw repo data, check_publish_readiness runs a checklist, and build_announcement_brief creates a writing brief. There is no overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., fetch_repo_info, check_publish_readiness, build_announcement_brief). The naming is predictable and uniform.

Tool Count3/5

With only 3 tools, the server is at the lower bound of the typical 3-15 range. While the domain is specific, the tool set feels slightly thin for a release announcer, missing tools for actual posting or scheduling.

Completeness2/5

The tools cover fetching, readiness checking, and brief creation, but lack tools for final draft generation or posting. Important lifecycle steps like creating releases or publishing announcements are absent, leading to significant gaps.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers