Skip to main content
Glama
Pawangunjkar

Artifact Registry MCP Server

by Pawangunjkar

artifact_save_credentials

Save registry credentials to the local persistent cache file.

Instructions

Save registry credentials to the local persistent cache file.

Purpose: Cache connection details so future sessions can reconnect automatically. When to Use: When pre-configuring staging/production environments without running queries. Behavior: Local file write to ~/.artifact-mcp-cache/credentials.json. Side Effects: Overwrites existing cached credentials for session_name.

Args: registry_type: 'nexus' or 'artifactory' base_url: Registry base URL token_or_password: Password, API Token, or Access Token username: Username (e.g. 'admin') session_name: Session name to store (default: 'default')

Input Schema

NameRequiredDescriptionDefault
base_urlYes
usernameNo
session_nameNodefault
registry_typeYes
token_or_passwordYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the local file write path (~/.artifact-mcp-cache/credentials.json) and the overwrite behavior for existing session_name credentials. It does not discuss credential security, permissions, or failure modes, leaving some behavioral gaps.

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 bold headings and an Args block, making it easy to scan. There is minor redundancy between the opening sentence and the 'Behavior' line about the local cache file, but no sentence is wasted.

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 mutation tool with no annotations and an existing output schema, the description covers the key side effect (local file write), overwrite risk, and all parameters. It is largely complete, though it omits security handling and permission prerequisites.

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

Parameters4/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 compensate, and it mostly does. The Args block explains all five parameters, including allowed registry_type values ('nexus' or 'artifactory'), examples for username, and the default for session_name. It could be stronger on token format expectations or parameter optionality.

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 specific verb and resource: 'Save registry credentials to the local persistent cache file.' It further clarifies the goal ('Cache connection details so future sessions can reconnect automatically'), which clearly separates it from siblings like artifact_connect and artifact_status.

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?

The 'When to Use' section gives a concrete scenario: pre-configuring staging/production environments without running queries. It does not name alternatives such as artifact_connect or explicitly state when not to use it, but the context is clear enough to guide selection.

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