publish-pilot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preflightA | Check that git, gh and the registry CLI are installed, which accounts are logged in, and the git identity. Starts no logins. Run this first. |
| install_toolA | Install a CLI tool with winget (Windows), brew (macOS) or apt (Linux). Known tools: git, gh, node, npm, python, cargo. After installing on Windows you may need to restart the MCP client so PATH updates. |
| check_namesA | Check that a package name is valid and free on the registry and that the GitHub repo name is free. When taken, returns the best free alternative (for npm, a scoped @user/name first). |
| loginA | Start the browser-based login for github (gh auth login --web), npm (npm login --auth-type=web), pypi or crates. Returns at once with a job id, the one-time code and the URL; the user signs in, does 2FA and clicks Authorize. Poll job_status every 1–2 minutes until running is false. |
| job_statusA | Get the status and recent output of a login or publish job. Optionally wait up to waitSeconds for it to finish, or send Enter to it. Without an id, lists all jobs. |
| scaffold_projectA | Create a standard project: source, tests, README, LICENSE, CHANGELOG, .gitignore, .gitattributes and a manifest (version 0.1.0, author from git config, repo URL, publishConfig for scoped npm). Adds CI and release workflows when repoUrl is set. Never overwrites existing files. |
| add_workflowsA | Write .github/workflows/ci.yml (install, lint, build, test on push and PR) and optionally release.yml (on v* tags: test, build, publish with trusted publishing via OIDC — skipped if the version exists — then a GitHub release from the CHANGELOG). Existing files are kept unless overwrite is true. |
| run_checksA | Run the project's install, lint, typecheck, build and test steps (npm scripts, a Python .venv with pytest + build, or cargo clippy/build/test). Stops at the first failure and returns its output. |
| scan_secretsA | Look for .env files, private keys and tokens in everything that would be committed. Reports file and line, never the secret itself. |
| inspect_packageA | Run the registry dry run (npm pack/publish --dry-run, twine check, cargo publish --dry-run), list the files that would be published, and flag junk or secrets. |
| git_commitA | git init (branch main) if needed, refuse when secrets or .env files would be committed, then stage everything and commit. |
| create_github_repoA | gh repo create --public|--private --source=. --push. Needs a commit and a GitHub login. If the repo already exists and is this folder's origin, just pushes. |
| publish_packageA | Publish from the terminal (npm publish [--access public], twine upload, cargo publish). Skips when the version already exists. Returns a job; the npm approval page is opened in the browser for the user. If the link expires, call again. |
| setup_trusted_publishingA | Connect the package to the GitHub release workflow (OIDC, no stored tokens). npm: runs |
| tag_and_releaseA | Create tag v from the manifest, push the branch and tag, and optionally create the GitHub release with notes from CHANGELOG.md. Never moves or deletes tags. |
| watch_workflowB | Wait for the latest run of a workflow (default release.yml) and report its result, with the failing log on failure. |
| bump_versionA | Bump the manifest version (patch/minor/major) and add a CHANGELOG entry. Does not commit. |
| verify_installA | In a brand-new temp folder, install the published package from the real registry (or git clone the repo) and run a command, such as the README quick start. Installed executables are on PATH. |
| notifyC | Show a desktop notification, e.g. 'Ready for your approval'. |
| open_urlA | Open an https page on github.com, npmjs.com, pypi.org or crates.io in the default browser. Other hosts are refused. |
| run_commandA | Run a command line (PowerShell on Windows, sh elsewhere) and return its output, redacted of tokens. Destructive commands (force-push, deleting tags/repos/releases, unpublish, recursive delete) are refused. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| publish_project | Step-by-step plan to take a project from nothing to a published GitHub repo and/or package using these tools. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool maps to a distinct stage of the publish workflow (preflight, login, checks, publish, release), and the descriptions clarify boundaries well. A few pairs—e.g. scaffold_project vs add_workflows, job_status vs watch_workflow—are related, but their scopes are still distinguishable.
Names are almost entirely lowercase snake_case and mostly follow a verb_noun pattern (install_tool, create_github_repo, publish_package). A few single-word or noun-first entries (preflight, login, notify, job_status, git_commit) are minor deviations, but the convention remains predictable.
21 tools is above the typical 3–15 range and feels heavy, but the server covers a comprehensive release lifecycle where most tools represent distinct, necessary steps rather than redundant helpers. Generic utilities like notify, open_url, and run_command add breadth without obvious bloat.
The surface covers the full lifecycle from environment preflight and project scaffolding through checks, publishing, trusted publishing, tagging/releasing, and post-publish verification. Minor gaps exist, such as no unpublish/deprecate/yank or broader package-settings management, but core workflows are well covered.