Skip to main content
Glama
Anselmoo

mcp-repo-release-tools

Apply rrt init (submitted by the init form)

rrt_init_run
Destructive

Initialize repository release tooling configuration using a target format. Running as a dry-run by default, it previews actions safely before applying changes.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo
targetNorrt-toml
dry_runNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.18.0

TDQS

A4.3/5.0
Behavior4/5

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

While destructiveHint already signals destructive potential, the description adds useful context: it shells out to a specific Python command, returns captured output, and defaults to dry_run=True for safety. It does not detail side effects when dry_run is false, but the added context is meaningful beyond the annotation.

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 compact and front-loaded with the core action and safety default. The second sentence explains the mechanism, and the final sentence provides routing advice without unnecessary filler.

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?

For a tool with three optional parameters, defaults, an output schema, and a destructive annotation, the description covers invocation mechanism, output capture, safety default, and usage context. The main gap is undocumented parameter semantics for `force` and `target`, but the overall picture is sufficient for selection and invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate for the three undocumented parameters. It only hints that `target` refers to a target format and implies `dry_run` controls safety; `force` is not explained, and valid target values or force/dry_run interactions are absent.

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 opens with a concrete action and resource: 'Run rrt init with the given target format.' It also identifies the tool as the submit target of the rrt_init form, which distinguishes it from the shell-oriented rrt_init sibling and makes its role clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit: this tool is the submit target of the rrt_init form, and agents working from a shell should run `rrt init` directly instead. It names the alternative and gives a clear when-not-to-use condition.

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