Skip to main content
Glama
mshegolev

harbor-registry-mcp

by mshegolev

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HARBOR_URLYesHarbor URL (no trailing slash)
HARBOR_PASSWORDYesPassword or robot token
HARBOR_USERNAMEYesHarbor username — robot account recommended
HARBOR_SSL_VERIFYNotrue/false. Default: true.true

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": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
harbor_list_projectsA

List Harbor projects, sorted by repository count (descending within the page).

Use this first to discover which Harbor projects exist before drilling in with harbor_list_repos / harbor_list_artifacts.

Pagination: if has_more is True, call again with page + 1. Note that sorting is per-page — agents that need a global ranking should aggregate across pages.

Returns: dict with keys projects_count / page / page_size / has_more / next_page / projects (list).

harbor_list_reposA

List repositories in a Harbor project.

Each repository is reported with artifact count and total pull count (useful for spotting unused repos before cleanup).

Pagination: if has_more is True, call again with page + 1.

harbor_list_artifactsA

List artifacts (tags) in a repository, newest first.

Each artifact carries digest, size, push/pull timestamps, scan status and vulnerability counts (if scanned).

Pagination: if has_more is True, call again with page + 1. For repositories with hundreds of artifacts prefer harbor_storage_report or harbor_cleanup_candidates which paginate internally.

harbor_storage_reportA

Full storage breakdown for a Harbor project.

Iterates every repository × every artifact and returns a sorted-by-size report — the canonical view for "what's eating up our quota?". Performs O(repos × artifacts) API calls; emits progress events through MCP Context.

harbor_cleanup_candidatesA

Suggest which artifacts could be deleted to reclaim space.

READ-ONLY — never deletes anything; just produces a list with reasons. Use harbor_delete_artifact / harbor_delete_untagged / harbor_delete_old_artifacts to act on the results.

Reasons emitted: - untagged — artifact has no tags (orphaned layer) - never_pulled — artifact has never been pulled (and is past the keep_latest_per_repo cutoff) - old_version — artifact is older than the keep_latest_per_repo newest tagged artifacts

harbor_delete_artifactA

Delete a single artifact by tag or digest.

DESTRUCTIVE & IRREVERSIBLE — Harbor immediately removes the manifest from its catalogue; the underlying blobs are reclaimed by the next GC sweep. There is no soft-delete or undo.

Returns the freed space and tag list for confirmation.

harbor_delete_untaggedA

Delete all untagged artifacts in a project (or single repository).

DESTRUCTIVE. Untagged artifacts are typically orphaned layers left behind after pushing a new tag of the same image — generally safe to delete. The full project sweep is opaque, so the response includes repos_scanned for visibility.

harbor_delete_old_artifactsA

Keep the N newest artifacts in a repository, delete the rest.

DESTRUCTIVE. dry_run=True is the default — the agent must explicitly set dry_run=False to actually delete. Each entry in to_delete carries a deleted field (True/False after real run, None in dry-run).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct operation: listing, reporting, or deleting. The cleanup candidate tool is clearly separate from the delete tools, and deletion tools are differentiated by scope (single, old, untagged). No overlapping purposes.

Naming Consistency4/5

Most tools follow the harbor_verb_noun pattern (e.g., harbor_delete_artifact, harbor_list_projects), but harbor_storage_report uses a noun_noun pattern, breaking consistency. The prefix and general style are otherwise uniform.

Tool Count5/5

Eight tools cover the essential operations for a Harbor registry: discovery (list projects, repos, artifacts), cleanup (candidates, delete single, delete old, delete untagged), and reporting (storage report). The count is well-scoped without being excessive.

Completeness5/5

The tool set provides comprehensive coverage for registry management: full lifecycle for artifacts (list, delete individual/bulk/untagged), project and repository exploration, storage analysis, and a cleanup candidate suggestion tool. No major gaps in functionality for the intended domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues