gh-autostar
Automatically stars GitHub repositories when an agent clones, installs, reads, or adopts a project. Provides tools and CLI commands for starring/unstarring repos, checking star status, configuring policies, and auditing actions via a local ledger.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@gh-autostar show me which repos you've starred for me this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
gh-autostar
用到了哪个 GitHub 项目,就给它点一颗星。
一个 MCP 插件。装上之后,agent 克隆仓库、把它装成依赖、读它的源码或 README、 采纳它的方案时,会自动替你给那个仓库点一颗 star —— 不用再手动去点。
跨宿主通用:WorkBuddy、Claude Code、Cursor、Cline、Windsurf、Claude Desktop、 Codex CLI,以及任何支持 stdio 传输的 MCP 宿主。

▶ 19 秒宣传片
初衷
我每天用着几十个开源项目 —— 克隆、读源码、装依赖,然后关掉页面。
从来没点过那颗星。
不是不感激。是那一刻总想着"等会儿再点",然后就再也没有等会儿了。星标是作者能收到的最轻的一种认可,也是我唯一能低成本给出的回报,偏偏它最容易被"下次再说"拖没。
所以做了这个:把"说声谢谢"这件事,从需要想起来,变成自动发生。
但前提是你真的用了它——不是见到链接就点,更不是刷量。所以触发条件被刻意收窄到克隆、装依赖、读源码、采纳方案这几种,并且带每日上限和全量审计。见 docs/POLICY.md。
Related MCP server: GitHub MCP Server
为什么是"三个入口"
只做 MCP 是不够的 —— MCP 工具得靠模型主动调用,而模型经常会忘。 所以触发做成了三层,可靠性逐层兜底:
层 | 机制 | 覆盖范围 | 可靠性 |
1 | MCP | 所有 MCP 宿主 | 高(模型多数会遵守) |
2 | 宿主 Hook(PostToolUse 扫描命令/URL) | Claude Code 等支持 hook 的宿主 | 确定(不依赖模型) |
3 | CLI | 任何脚本、git 包装器、手动 | 确定 |
三层共用 src/core,所以无论从哪条路进来,判断逻辑、幂等、账本完全一致。
┌──────────────────────────────┐
agent 用到仓库 ──▶ │ parseRepo() 收敛成 owner/repo│
└──────────────┬───────────────┘
▼
┌──────────────────────────────┐
│ policy.decide() 该不该点? │
│ 开关/黑名单/幂等/配额/过滤 │
└──────────────┬───────────────┘
star ────┴──── skip
▼ ▼
PUT /user/starred 写账本说明原因
▼
ledger.jsonl(审计)快速开始
git clone https://github.com/Yolgz-sys/gh-autostar.git
cd gh-autostar
npm install
# 1. 确认能读到你的 GitHub 登录态
gh auth status # 没登录就先 gh auth login
node bin/gh-autostar.js status
# 2. 先跑 dry-run 三天,看看它到底会点为哪些仓库(不会真的点)
node bin/gh-autostar.js config mode=dry-run
node bin/gh-autostar.js log
# 3. 看清楚了再放开
node bin/gh-autostar.js config mode=auto然后把 MCP server 接进你的宿主,配置片段见 adapters/mcp-configs.md。
接好之后,在宿主里问一句"你有 ensure_starred 工具吗",能答"有"就算通了。
接入自检
不确定配好没有,跑这个(强制 dry-run,不会点星):
node scripts/verify-install.mjs
node scripts/verify-install.mjs --config=~/.cursor/mcp.json # 检查其它宿主它会校验配置文件、真的拉起 server 走完 MCP 握手、调一次 star_status 看返回,
逐项打勾。比"重启宿主碰运气"省事。
注意:配置写进去不等于生效。MCP 宿主通常在启动时读取配置,写完要重启宿主; WorkBuddy 还额外需要到「连接器管理 → 自定义连接器」对新 server 点一次信任。 自检脚本能证明 server 本身没问题,但证明不了宿主那边已经加载 —— 那是宿主的状态。
命令
gh-autostar touch <repo...> # 记录"用到过"并点星(hook / 包装脚本用它)
gh-autostar star <repo> # 直接点星
gh-autostar unstar <repo> # 取消星标
gh-autostar status # 开关、模式、今日配额、登录状态
gh-autostar log [-n 50] # 审计账本
gh-autostar config # 打印配置
gh-autostar config mode=dry-run # 改配置
gh-autostar config --allow=foo/bar # 加白名单
gh-autostar config --deny=foo/bar # 加黑名单
gh-autostar hook # 从 stdin 读宿主事件(hook 专用)仓库参数很宽松,下面都能认:
facebook/react
https://github.com/facebook/react
https://github.com/facebook/react/tree/main/packages
git@github.com:facebook/react.git
github:facebook/react # npm 简写配置
默认位置 ~/.gh-autostar/config.json(可用 GH_AUTOSTAR_HOME 改)。
键 | 默认 | 说明 |
|
| 总开关 |
|
|
|
|
| 每日上限, |
|
| 白名单:跳过质量过滤(仍然受配额与黑名单约束) |
|
| 黑名单:永不点星, |
|
| 开启后只有白名单仓库会被点星 |
|
| 低于该星数的仓库跳过,用来挡测试仓库与刷星垃圾 |
|
| 跳过 fork |
|
| 不给自己名下的仓库点星 |
环境变量优先级高于配置文件:
GH_AUTOSTAR_DISABLED=1 # 临时关闭
GH_AUTOSTAR_MODE=dry-run # 临时改模式
GH_AUTOSTAR_DAILY_CAP=3 # 临时改配额
GITHUB_TOKEN=ghp_xxx # 缺省时读取 gh CLI 登录态关于 token:不配置任何变量也能用,程序会执行 gh auth token 拿登录态。
但 MCP server 是被宿主 spawn 的子进程,PATH 往往不等于你终端里的 PATH
(GUI 启动的宿主常常只继承系统级 PATH),所以 resolveToken() 在 gh 找不到时
会继续尝试 C:\Program Files\GitHub CLI\gh.exe、%LOCALAPPDATA%\GitHubCLI\gh.exe、
/opt/homebrew/bin/gh 等常见位置。都失败才判定未认证 —— 此时 star_status 会明确告诉你。
什么算"用到了"
刻意收窄了,避免变成"见到 GitHub 链接就点"的刷星器:
✅
git clone/gh repo clone某仓库✅ 把它装成依赖(
npm i github:owner/repo、go get、pip install git+...)✅ 读它的源码、README、文档(WebFetch 到
github.com/owner/repo/...)✅ 在答案里采纳了它的方案
❌ 只是搜索结果里扫到一眼
❌ 批量遍历 trending / 依赖树
❌ 用户自己的仓库
安全边界
自动点星这件事本身有争议,所以内置了几道硬约束,docs/POLICY.md 里写了完整理由:
每日上限(默认 10 颗)—— 远低于任何会触发平台风控的量级;
幂等 —— 同一仓库永不重复点,本地账本 + 远端状态双重校验;
黑名单优先 —— 任何自动化都绕不过去,包括
--force;全量审计 —— 每一次"点了什么 / 为什么没点"都写进
ledger.jsonl,可回溯、可撤销;一键关闭 —— 用户说一句"别点星了",
configure_autostar直接关掉。
如果你打算把它分发给别人:默认应该设成
dry-run,让用户自己看三天账本再决定放开。 拿它给指定的几个仓库刷星,或者多账号跑,是明确不该做的事。
目录结构
gh-autostar/
├── bin/gh-autostar.js # CLI
├── src/
│ ├── core/
│ │ ├── repo.js # 仓库标识解析(最脏的活)
│ │ ├── config.js # 配置加载与校验
│ │ ├── ledger.js # append-only JSONL 账本
│ │ ├── github.js # GitHub REST 客户端
│ │ ├── policy.js # 纯函数策略引擎
│ │ └── star.js # 编排层
│ └── mcp/server.js # MCP server(含 instructions)
├── hooks/lib.js # 宿主 hook 公共实现
├── scripts/verify-install.mjs # 接入自检(握手 + 工具调用)
├── adapters/
│ ├── mcp-configs.md # 各宿主配置片段
│ └── claude-code/ # Claude Code 插件 + hook
├── tests/ # 47 个用例
└── docs/POLICY.md开发
npm test # 47 个用例,含真实 MCP 握手测试
npm start # 直接跑 MCP server(stderr 有就绪日志)加新宿主只需要两件事:在 adapters/mcp-configs.md 里加配置片段;
如果该宿主有 hook 机制,写一个像 adapters/claude-code/hook.js 那样的薄壳,
把 stdin 事件转给 gh-autostar hook 即可。
License
MIT
Available Tools
6 toolscheck_starA
查询某个 GitHub 仓库当前是否已被当前账号点星(同时检查 GitHub 远端与本地账本)。只读操作。
Inputs: repo (required).
configure_autostarB
修改自动点星配置:开关、模式、每日上限、白名单/黑名单增删。用户要求"别点星了""只给某几个仓库点"时使用。
Inputs: mode, enabled, dailyCap, denylistAdd, +3 more.
ensure_starredA
当你在本轮对话中实际使用、阅读或采纳了某个 GitHub 仓库时调用,为该仓库点一个 star。幂等,可安全重复调用。
Inputs: repo (required), reason.
list_recent_starsA
列出最近的点星记录(审计用),包含时间、仓库、来源与原因。
Inputs: limit.
star_statusA
查看自动点星的状态:总开关、模式、今日已用配额、账号登录情况、黑名单等。
Inputs: no named parameters.
unstarB
撤销对某个 GitHub 仓库的星标(误点或用户要求取消时使用)。
Inputs: repo (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 6 tools
Each tool maps to a distinct action: starring (ensure_starred), verifying (check_star), removing (unstar), configuring (configure_autostar), and two read-only views. The only mild overlap is between star_status (global config/state) and list_recent_stars (history log), but the descriptions make the boundary clear enough.
Most names follow verb_noun (check_star, list_recent_stars, configure_autostar), but ensure_starred uses a past-participle form, unstar is a bare verb, and star_status leads with a noun. The conventions are mixed yet still readable and predictable enough to infer intent.
Six tools cover the full lifecycle of a narrow, well-defined domain without redundancy. Each tool earns its place: act, verify, undo, inspect state, audit, and configure.
Star/unstar/check plus status, audit history, and configuration covers the core lifecycle with no dead ends. Minor gaps exist—no batch operations and no dedicated query for current whitelist/blacklist contents beyond what star_status exposes.
Maintenance
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- AlicenseBqualityCmaintenanceA powerful MCP server that helps you discover relevant repositories from your own starred list on GitHub using BM25 keyword ranking and Gemini Semantic Search.219MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to directly manage GitHub repositories, including PRs, issues, and code search, using natural language.MIT
- AlicenseAqualityDmaintenanceMCP server that provides AI coding agents automatic access to AGENTS.md documentation from GitHub repositories, enabling understanding of codebase conventions and patterns.2Apache 2.0
- AlicenseAqualityDmaintenanceAn MCP server that caches your GitHub starred repositories in a local SQLite database and lets you search, list, and retrieve details about them through any MCP client (Claude Desktop, Cursor, VS Code, etc.), with automatic freshness checks via GitHub's ETag mechanism.51MIT