Artifact Registry MCP Server

Overview Schema Source Related Servers Discussions Admin

artifact_promote_release

Promote immutable artifacts from staging to production release repositories without rebuilding, preserving provenance and cryptographic integrity for supply-chain promotion.

Instructions

Promote an immutable artifact from staging/snapshot to production release repository.

⚠️ CONFIRMATION-GATED MUTATING TOOL: Requires confirm=true to execute.

Promotes a tested, immutable component from staging (e.g. 'dev-local', 'maven-staging') to production release (e.g. 'prod-release', 'maven-releases') without rebuilding, maintaining complete provenance and cryptographic integrity.

Purpose: Supply-chain promotion between pipeline stages. When to Use: In Workflow 2 after integration/smoke tests pass. Behavior: MUTATING. Copies component to target release repository. Side Effects: Modifies target release repository contents.

Args: source_repo: Source repository key (e.g. 'dev-local', 'staging-repo') target_repo: Target release repository key (e.g. 'prod-release', 'maven-releases') artifact_or_build_name: Name of the artifact or build component (e.g. 'cart-service') version: Version string to promote (e.g. '1.5.0') confirm: Must be True to execute promotion (default: False) session_name: Session to use (default: 'default')

Input Schema

Name	Required	Default
`confirm`	No
`version`	Yes
`source_repo`	Yes
`target_repo`	Yes
`session_name`	No	default
`artifact_or_build_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden well: it identifies the tool as MUTATING, confirmation-gated, and side-effecting because it modifies the target release repository. It could be slightly stronger by stating permission requirements or overwrite/failure behavior.

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?

The description is front-loaded with the confirmation warning and organized into useful sections. There is minor repetition between the opening sentence and the Purpose/Behavior sections, but the structure is efficient for a six-parameter mutating tool.

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

Completeness5/5

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

Given the absence of annotations, 0% schema description coverage, and the presence of an output schema, the description provides enough context to select and invoke the tool correctly. It covers purpose, usage timing, mutation behavior, side effects, confirmation, and every argument.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all parameters, and it does. Each argument is named with meaning and examples, and defaults for confirm and session_name are stated.

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 uses a specific verb and resource: promote an immutable artifact from staging/snapshot to a production release repository. It clearly distinguishes promotion from sibling operations such as upload, cleanup, search, and checksum verification.

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

Usage Guidelines4/5

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

It explicitly states when to use the tool: in Workflow 2 after integration/smoke tests pass. It also makes the confirmation requirement clear, though it does not name alternatives or explicit when-not conditions.

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

Deploy Server