Skip to main content
Glama
Anselmoo

mcp-repo-release-tools

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
rrt_configA

Read the repo's resolved [tool.rrt] policy.

Version targets, pin targets, changelog file, release branch pattern, folder rules. Call this before proposing any release-related change so you act on configured policy rather than assumptions. This returns the resolved config as structured data — a config-load error comes back as a typed ConfigError rather than a nonzero exit — but it does NOT run the per-target checks rrt config --validate does (target/pin/docs/folder .validate()); use rrt_release_check, rrt_folder_check, or rrt_docs_check for those.

rrt_doctorA

Check whether hooks, workflows, and the artifact-protection lens are wired correctly.

Covers pre-commit, lefthook, husky, GitHub Actions workflows, and CI artifact-protection. Use before recommending a hook or workflow change, and when a hook did not fire as expected. Returns one CheckResult per component with ok + severity — no output parsing.

rrt_healthA

Return the health check results from .rrt/health.lock.toml.

Reflects the last snapshot-writing run, not current state; run the CLI check to compare against the working tree. If your client can read files directly, Read .rrt/health.lock.toml is equivalent. This lock can hold results from three separate commands — rrt doctor --snapshot (pre-commit/lefthook/husky/ workflows), rrt eol --snapshot, and rrt folder --snapshot — so prefer rrt_doctor, rrt_eol, or rrt_folder_check for a live check of the part you actually need, not rrt_doctor alone.

rrt_driftA

Return source drift state from .rrt/drift.lock.toml (file hashes and symbols).

Reflects the last rrt drift generate, not current state; run rrt drift check to compare against the working tree. If your client can read files directly, Read .rrt/drift.lock.toml is equivalent.

rrt_treeA

Return the repository tree snapshot from .rrt/tree.lock.toml.

Reflects the last rrt tree --snapshot, not current state — this tool does NOT run rrt tree --check and cannot tell you whether the working tree still matches it. There is no MCP tool for that check; use the CLI. If your client can read files directly, Read .rrt/tree.lock.toml is equivalent.

rrt_artifactsA

Return the artifact integrity map from .rrt/artifacts.lock.toml.

Reflects the last rrt artifacts --snapshot, not current state; run the CLI check to compare against the working tree. If your client can read files directly, Read .rrt/artifacts.lock.toml is equivalent.

rrt_versionA

Read the current version of every configured version group from its primary target.

Use whenever a version number is about to appear in a commit message, changelog heading, docs string, or release note — this is the authoritative value, not whatever a file happened to say. Read-only.

rrt_bumpA

Preview or apply a version bump — use instead of editing version strings by hand.

This is the same pipeline as rrt bump (version targets, pins, changelog promotion, lockfile and generated-asset refresh, release branch + commit), so a partial hand-edit will diverge. dry_run=True previews everything and writes nothing. Each result's changed_paths lists every file the bump touched (or would touch under dry_run), relative to the repo root.

level: major | minor | patch | alpha | beta | rc. dry_run=True by default. group: restrict the bump to one [tool.rrt] version group; omit to bump every configured group (one :class:BumpGroupResult per group either way).

Runs the SAME pipeline as the rrt bump CLI command (preflight, version targets, pin targets, changelog promotion/generation, lockfile and generated-asset refresh, then release-branch checkout + commit) via :mod:repo_release_tools.commands.bump's shared stage functions, so an MCP bump and a CLI bump of the same repo produce identical results (fixes defect D9: the previous MCP bump only rewrote version-target files and skipped pins, changelog, lockfiles, generated assets, and git branch/commit entirely).

rrt_validate_branchA

Check a branch name against this repo's configured type allow-list before you create it.

Cheaper than creating it and having the pre-commit hook reject it. Honors extra_branch_types from config, which a hardcoded regex would miss.

rrt_validate_commitA

Check a commit subject against Conventional Commits as this repo enforces it, before you commit.

Prefer this over rrt-hooks commit-msg in a shell: the subject is passed as a string argument, so backticks, quotes, !, and $ in the message cannot be mangled by shell quoting.

rrt_changelogA

Read the changelog.

Use before adding an entry, so you do not duplicate one that is already there, and before a bump, to see what will be promoted. section='unreleased' (default) returns parsed pending entries; section='full' returns the raw file. Read-only — writing an entry needs the CLI or hook workflow (rrt-hooks update-unreleased); do not hand-edit the [Unreleased] section while that hook is active.

rrt_branch_newA

Derive a compliant branch name from a type + description.

When dry_run=False, checks it out. Use instead of git checkout -b with a hand-written name — it also returns a matching Conventional Commit title to use for the first commit, though nothing enforces that the caller actually uses it.

commit_type: feat|fix|chore|docs|refactor|test|ci|perf|style|build. dry_run=True by default.

rrt_publish_snapshotA

Force-push a single-commit snapshot of tracked content to a secondary remote.

dry_run=True by default. The force-push requires BOTH dry_run=False AND confirm=True -- mirroring the CLI's rrt git publish-snapshot, which requires an explicit --yes-i-know-this-overwrites-remote-history flag in addition to not passing --dry-run (two independent signals for one destructive, history-rewriting operation). If confirm is omitted or False, the call is always treated as a dry-run preview, regardless of dry_run.

rrt_eolA

Check the host runtime and project minimum versions against EOL policy.

Use before raising or lowering a minimum supported version, and when deciding whether to drop a version from a CI matrix. Read-only — never writes to .rrt/health.lock.toml. Set fetch_live=True to refresh EOL data from endoflife.date instead of the bundled snapshot.

rrt_release_checkA

Verify every version target, pin target, and changelog file resolves and agrees, per version group.

Use as the pre-release gate and after any edit that touches a version string in docs or config — pin drift is silent otherwise. Read-only — never modifies files.

rrt_sync_checkA

List upstream package versions newer than the current project version.

Reads the group's [tool.rrt.upstream] package config and queries the configured registry (PyPI/npm/NuGet/crates.io/Packagist). Read-only — never applies a bump. Requires network access to the registry.

rrt_folder_checkA

Check the repo layout against [tool.rrt.folders] policy or named built-in templates.

Use before creating a new top-level directory or moving a module, so you place it where policy expects. Read-only — never scaffolds files.

rrt_docs_checkA

Check whether .rrt/docs.lock.toml is current against source-owned docs.

Use after editing any source docstring that feeds generated documentation, before opening a PR — CI fails on this drift. Read-only — never regenerates or writes files. If stale, run rrt docs generate --format toml to refresh. Covers .rrt/docs.lock.toml only; rrt docs map --check has no tool here — use the CLI. Also reports published-docstring skeleton violations in skeleton_issues when the project configures [tool.rrt.docs.skeleton].

rrt_health_dashboardA

Health overview: Metric summary, health Ring, per-lock status chart, check cards, and detail table.

Renders a UI widget for a human to look at — if you need the values to reason over, call rrt_health / rrt_doctor instead.

rrt_version_overviewA

Version target map: each configured file, kind, and current version.

Renders a UI widget for a human to look at — if you need the primary-target values to reason over, call rrt_version instead. Unlike this dashboard, which reads every configured target, rrt_version returns only each group's primary target; for secondary/pin target consistency use rrt_release_check.

rrt_doctor_dashboardA

Doctor check results: pass-rate Ring, per-check Metrics, status cards, and detail table.

Renders a UI widget for a human to look at — if you need the values to reason over, call rrt_doctor instead.

rrt_tree_dashboardA

Repository tree: snapshot Metric cards, per-directory bar chart, and clean file table.

Renders a UI widget for a human to look at — if you need the values to reason over, call rrt_tree instead (it is still a snapshot, not a live check).

rrt_initA

Form to initialize rrt configuration — pick target format, preview, then apply.

Renders a UI widget for a human to fill in — if you are an agent working from a shell, run rrt init directly instead.

rrt_init_runA

Run rrt init with the given target format. Defaults to dry_run=True for safety.

This is the submit target of the rrt_init form — it shells out to python -m repo_release_tools.cli init and returns the captured output. If you are an agent working from a shell, run rrt init directly instead; you gain nothing by going through this tool.

rrt_locks_overviewA

All lock files at a glance: status donut chart, Carousel of lock summaries, and full detail table.

Renders a UI widget for a human to look at — if you need the values to reason over, call rrt_health / rrt_tree / rrt_artifacts / rrt_drift instead.

generate_prefab_uiA

Execute Prefab Python code in a sandbox and render the result.

The code runs in a Pyodide WASM sandbox with full Python support. Import everything you use. Use the components tool to look up available components and their import paths.

Always use PrefabApp as the outermost context manager — this enables streaming so the UI renders progressively as code is written:

from prefab_ui.components import Column, Heading, Text, Row, Badge
from prefab_ui.app import PrefabApp

with PrefabApp() as app:
    with Column(gap=4):
        Heading("Dashboard")
        with Row(gap=2):
            Text("Revenue: $1.2M")
            Badge("On Track", variant="success")

For interactive UIs, pass initial state as a dict and use .rx on stateful components for reactive bindings:

from prefab_ui.components import Column, Slider, Text
from prefab_ui.app import PrefabApp

with PrefabApp(state={"threshold": 50}) as app:
    with Column(gap=4):
        slider = Slider(value=50, min=0, max=100, name="threshold")
        Text(f"Threshold: {slider.rx}%")

slider.rx produces {{ threshold }}, a template expression that resolves against client-side state. Use Rx("key") directly, or apply pipe filters: Rx("balance").currency() produces {{ balance | currency }}.

Available pipes: upper, lower, currency, length, json, round(n), default(val), truncate(n).

Charts live in prefab_ui.components.charts:

from prefab_ui.components.charts import BarChart, ChartSeries

BarChart(
    data=[{"month": "Jan", "rev": 100}, {"month": "Feb", "rev": 200}],
    series=[ChartSeries(data_key="rev", label="Revenue")],
    x_axis="month",
)

Values passed via data are available as global variables in the code. Python features like loops, f-strings, and comprehensions all work.

Layout patterns:

  • Card sub-components (CardHeader, CardContent, CardFooter) have built-in padding. Don't add extra padding to them. For a simple card without sub-components, use Card(css_class="p-6").

  • Use Grid(columns=N, gap=4) for equal-width cards or panels. Grid handles sizing automatically — no flex classes needed. For unequal widths, pass a list: Grid(columns=[2, 1], gap=4) gives a 2:1 ratio.

  • Row is for inline elements (badges, icons + text, buttons). Prefer Grid when children should have equal or proportional widths. Row does not wrap by default.

  • Column and Row accept gap (Tailwind scale: 1-12), align (cross-axis), and justify (main-axis) as native props — prefer these over raw css_class for spacing.

  • Use css_class="overflow-hidden" on containers if chart or content edges should clip to the container boundary.

Args: code: Python code that builds a Prefab component tree. data: Values injected as variables in the sandbox namespace. sandbox: A Sandbox instance. If not provided, a new one is created on each call.

search_prefab_componentsA

Search the Prefab component library.

Use this tool to look up exact argument names, accepted values, and usage examples before writing component code. The skill covers patterns and layout; this tool has the API details.

The query matches component names and descriptions. Space-separated terms match independently, so "Card Badge Metric" returns all three.

When a query matches a small number of components, full details (docstrings, args, examples) are shown automatically. For broad searches, a compact listing is returned instead. Use detail to override this behavior.

Args: query: Filter by component name or description. Space-separated terms are OR-matched. detail: Show full docstrings and args. Defaults to automatic (detailed for ≤5 matches, compact otherwise). limit: Max components to return in detail mode (default 8). No limit in compact mode.

Prompts

Interactive templates invoked by user choice

NameDescription
release_workflowStep-by-step rrt release guide for the given semver bump level.
version_strategyRecommend the correct semver bump level based on a summary of changes.
branch_strategySuggest a conventional branch type and slug for a task description.
commit_message_guideDraft a Conventional Commits subject line from staged changes and branch context.
changelog_entryDraft a Keep-a-Changelog bullet point from a commit or change summary.
config_setupStep-by-step guide for adding [tool.rrt] configuration to a project.
release_readinessPre-release verification checklist: health, changelog, version, branch, and CI status.

Resources

Contextual data attached and managed by the client

NameDescription
resource_versionCurrent installed version of repo-release-tools.
resource_configResolved rrt configuration as JSON.
resource_config_schemaJSON Schema for [tool.rrt] configuration — discover valid keys and value types.
resource_changelogFull content of the repository CHANGELOG.md.
Prefab Generative Renderer
Prefab Renderer (rrt_health_dashboard)
Prefab Renderer (rrt_version_overview)
Prefab Renderer (rrt_doctor_dashboard)
Prefab Renderer (rrt_tree_dashboard)
Prefab Renderer (rrt_init)
Prefab Renderer (rrt_locks_overview)

TDQS

A3.9/5.0

Scored across 27 tools

Disambiguation4/5

Most rrt_* tools target distinct resources (branch, config, health, drift, tree, artifacts, version, changelog), and descriptions clarify read-only vs. check vs. action. The main ambiguities are rrt_init vs. rrt_init_run and the dashboard/overview tools that parallel their data counterparts, though the descriptions explicitly steer agents away from the UI variants.

Naming Consistency3/5

There is a consistent rrt_ prefix and snake_case style, but the verb/noun pattern is mixed: some tools are noun-only (rrt_health, rrt_tree, rrt_changelog), some are verb_noun (rrt_validate_branch, rrt_release_check), and rrt_doctor is a noun used as a verb. The two prefab tools (generate_prefab_ui, search_prefab_components) break the rrt_ prefix entirely, making the set feel like two naming systems.

Tool Count2/5

At 27 tools, the server exceeds the 25-tool threshold and feels heavy for its purpose. The core release-check/bump/version functionality is reasonably scoped, but the five dashboards, two init tools, and two prefab UI tools inflate the surface and could be split out or removed.

Completeness4/5

The release lifecycle is well covered: branch validation, version reading, bumping, commit validation, changelog reading, release checks, sync checks, folder/docs checks, and publish-snapshot all exist. Minor gaps remain, such as no MCP tool for the live tree check, no direct changelog write, and no docs-map check, but these are explicitly noted as CLI-only rather than silent dead ends.

Maintenance

ActivityActive
ResponsivenessWithin a week