Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/agentic-community/mcp-gateway-registrynpx agentmods add skills/agentic-community/mcp-gateway-registry/release-notesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/agentic-community/mcp-gateway-registry/release-notes)<a href="https://agentmods.dev/skills/agentic-community/mcp-gateway-registry/release-notes"><img src="https://agentmods.dev/badge/skills/agentic-community/mcp-gateway-registry/release-notes.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.05427 |
| Opus 5 | $0.00030 | $0.02714 |
| Sonnet 5 | $0.00012 | $0.01085 |
| Haiku 4.5 | $0.00006 | $0.00543 |
Grade A, and why
release-notes scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 477 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Notes Skill
Use this skill when the user wants to create release notes for a new version. This skill gathers all changes since a previous release, writes structured release notes following the project's established format, tags the repo, and pushes.
Input
The skill takes a version tag as input:
- Format:
{major}.{minor}.{patch}(e.g.,1.24.0) - novprefix, semver only - Older releases (pre-
1.23.0) used avprefix (e.g.,v1.0.22) - existing artifacts underdocs/release-notes/v*.mdand tagsv1.0.xare preserved as-is, but new releases must use the bare-semver convention - If the user provides a
v-prefixed version for a new release, strip the prefix and confirm
Output
Creates a release notes file in docs/release-notes/ and tags the repo:
docs/release-notes/{version}.md- Release notes markdown file (e.g.,docs/release-notes/1.24.0.md)- Git tag
{version}pointing to the commit that includes the release notes
Workflow
Step 0: Confirm the Pre-Release Smoke Test Was Run (Gate)
Before doing any release-notes work, confirm the end-to-end release smoke test
(tests/e2e_release_test.py) has been run
against a live gateway and passed. This suite exercises the surface a release
must not break: the registry is up, the built-in airegistry-tools server is
healthy and its search tool works, servers/agents/skills support full CRUD,
semantic search returns results, security scans run, and one real external MCP
server (AWS knowledge base) is reachable end to end through the gateway proxy.
-
Ask the user, using AskUserQuestion, whether they have already run the release smoke test and it passed. Offer these options:
- "Yes, it passed" (proceed to Step 1)
- "No, run it now" (Recommended - run it for them, see below)
- "Skip it" (proceed, but see the warning below)
-
If the user asks you to run it, run against the target gateway. It needs an admin/M2M bearer token file (Keycloak tokens expire in ~5 minutes, so regenerate first if unsure):
# Local gateway with an admin token at ./.token uv run python tests/e2e_release_test.py --token-file .token --registry-url http://localhost # Remote gateway uv run python tests/e2e_release_test.py \ --registry-url https://<gateway-host> --token-file .oauth-tokens/ingress.jsonThe runner prints a pass/fail table and exits non-zero if any test fails.
- If it exits non-zero (any FAILED), STOP. Do not proceed with the release. Report which tests failed and their messages, and help the user investigate. A release must not be cut with a failing smoke test.
- SKIPPED is acceptable (e.g. the external AWS test skips on a network outage rather than failing) - only FAILED is a hard block.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 477 lines · 59 tokens per session scan A 78c40c77df3c
release-notes is a skill published in the GitHub repository agentic-community/mcp-gateway-registry (895 stars, last pushed 5d ago), licensed Apache-2.0. It adds 59 tokens to every session and 5,427 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle…
github-repo-management
Clone, create, fork repos; manage remotes, releases.
merge
The ship gate — the only skill that merges. --staging merges the feature→staging PR on green CI, deploys, verifies, emits a human test script and stamps the staging sign-off on approval. --production ships the double-confirmed release to main and deploys production. Never self-certifies staging; nothing reaches main…
release
Cut and publish Moraine releases from a version argument such as /release X.Y.Z in Kiro or a request to use $moraine-dev:release in Codex. Use when Codex or Kiro is asked to run Moraine's release process, bump release-managed versions, create and merge the release PR, push the vX.Y.Z tag, update GitHub release notes…
github-pr-workflow
GitHub PR lifecycle: branch, commit, open, CI, merge.
changelog-generator
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.