Repository Manager

Install

rm_projects_install

Bulk install, build, and validate Python projects. Start validation as a background job and poll status with the returned job ID.

Instructions

Install (rm_projects). Bulk install, build, and validate Python projects.

The 'validate' action submits validation as a background job and returns a job_id immediately. Use 'validate_status' with that job_id to poll progress and retrieve results once complete.

Input Schema

Name	Required	Description	Default
`extra`	No	Install group (e.g. 'all') for 'install'.	all
`job_id`	No	Job ID to check status for 'validate_status' action.
`summary`	No	For 'validate'/'validate_status': return a COMPACT roll-up (counts + failed set + running names) instead of the full per-job dump. Keeps responses inline-returnable at thousands of repos. Set False for the full per-job detail.
`threads`	No	Parallel workers.
`auto_bump`	No	Automatically run phased_bumpversion if validation passes. Begins at the lowest phase that has repository changes (and cascades to every later phase), skipping unchanged upstream phases.
`auto_push`	No	Automatically run phased_push if validation passes. Begins at the lowest phase with unpushed work, skipping the inter-phase waits of unchanged upstream phases.
`bump_part`	No	The part of the version to bump (e.g. minor, patch, major) if auto_bump is used.	minor
`output_dir`	No	Directory to write the validation-reports for 'validate'.
`commit_code`	No	For 'validate': after validation passes and BEFORE the version bump, concurrently stage (git add -A), run pre-commit, and commit feature code across ALL targeted repos. Ensures untracked/new files are committed (not left for the push safety net). The bump then waits on this step. Use with commit_message.
`failed_only`	No	For 'validate': target ONLY repositories whose most-recent validation failed (the remediation loop). Ignored if 'repositories' is given. Forces re-validation of that set.
`repositories`	No	Comma-separated list of specific repositories to target.
`commit_message`	No	Commit message for the commit_code step. Required when commit_code=True.
`generate_report`	No	Generate validation report directory for 'validate'. Default True.
`prune_worktrees`	No	For 'validate' with auto_bump/auto_push: after the release, prune session worktrees already merged into main (and dangling admin pointers). DESTRUCTIVE. Default False — the release still runs the audit and REPORTS the safe_to_prune/do_not_disturb classification under 'worktree_hygiene_job_id' WITHOUT deleting anything. Never touches active/in-flight or orphaned worktrees.
`force_revalidate`	No	If true, bypass validation cache and force re-validation of all projects.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

B3.3/5.0

Behavior3/5

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

The description adds real behavioral context beyond the annotations: the validate action is asynchronous, returns a job_id immediately, and requires polling. Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety baseline is covered, but the description says nothing about the mutation side effects implied by auto_push/auto_bump/commit_code or about the schema's explicitly DESTRUCTIVE prune_worktrees flag. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with what the tool does and then the async validate/poll contract. Nothing is padded and no sentence is wasted. It is arguably too terse for a 15-parameter tool, but that is a completeness issue rather than a structural one.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 15-parameter bulk orchestration tool with release-side effects (auto_bump, auto_push, commit_code, prune_worktrees, failed_only remediation loop) and an output schema, yet the description only explains the validate-async polling pattern. The install and build actions named in the first sentence get no elaboration, and the description references 'validate'/'validate_status' actions even though the schema exposes no action parameter — leaving an agent unclear how the actions are selected. Given the complexity, this is thinner than it should be.

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

Parameters3/5

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

Schema description coverage is 100% and the per-parameter descriptions are unusually rich (including the async job_id semantics and the DESTRUCTIVE warning on prune_worktrees), so the schema carries the parameter burden. The tool description adds no parameter-level syntax or format detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Bulk install, build, and validate Python projects' under the rm_projects namespace. It is clear what the tool does, but it never distinguishes itself from siblings such as repository_manager_install_projects, rm_projects_build, rm_projects_validate, or rm_projects_validate_status, which overlap heavily with the three actions named.

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

Usage Guidelines3/5

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

It gives one piece of routing advice — that 'validate' returns a job_id and that 'validate_status' should be used to poll it — which is genuinely useful. However, there is no guidance on when to use this tool versus the many sibling install/build/validate tools, and no explanation of which of the three actions (install, build, validate) applies when.

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

Deploy Server