Harbor AIops
<!-- mcp-name: io.github.AIops-tools/harbor-aiops -->
# Harbor AIops
Governed Harbor container-registry operations with 39 MCP tools and corresponding CLI commands. Every call is audited and budgeted by the bundled governance harness. Artifact scan, tag creation and high-risk tag deletion have dry-run previews; uncertain results are reported as `outcomeUnknown`.
## What it checks
- Component health and system volume use.
- Projects, repository inventory, artifacts, tags, vulnerability reports, quotas and project audit logs.
- Registry statistics, project members, tag immutability rules, labels and robot metadata (secrets redacted).
- Latest registry-wide and scheduled scan metrics, plus bounded artifact scan report logs.
- Guarded deletion of one proven, mutable tag with an absence post-check.
- Garbage collection execution history.
- GC execution details and bounded plain-text logs.
- Replication policies, executions, tasks and bounded task logs.
- Retention policy, execution, tasks and bounded task logs by actual IDs.
- `harbor_diagnose` combines health, volume, GC and replication observations. Failed probes appear as errors with `data: null`.
Lists have `items`, `returned`, `limit`, and measured `truncated` fields. They are capped at 500 records per call.
## Setup from source
Requires Python 3.11+, `uv`, and a Harbor instance. Install locally with `uv sync --dev`. Run `uv run harbor-aiops init` to configure an HTTPS target and encrypt its password, or create `~/.harbor-aiops/config.yaml` with a `targets` list:
```yaml
targets:
- name: primary
host: harbor.example.com
username: robot$ops
scheme: https
port: 443
verify_ssl: true
timeout: 30
```
Run `uv run harbor-aiops secret set primary`, then `uv run harbor-aiops doctor` and `uv run harbor-aiops diagnose`. The MCP entry point is `uv run harbor-aiops-mcp`. Set `HARBOR_AIOPS_MASTER_PASSWORD` for noninteractive secret-store access. TLS verification is enabled by default; `ca_file` accepts a custom CA PEM.
## Scope and verification
The `scan-artifact` command starts an asynchronous scan and reports an unknown final outcome until its status is checked. `create-tag` proves the tag was absent and checks that it appeared after the write. `delete-tag` requires an exact mutable tag on the specified digest, previews the target and confirms absence after deletion. Neither tag write mints an undo token because immutability and later artifact changes can make the inverse unsafe. Retention execution, replication restart, GC start/stop, artifact deletion and policy changes remain outside this release until their actual outcomes and recovery paths can be verified on disposable Harbor. See [verification](docs/VERIFICATION.md). Missing operations and live-environment feedback are welcome as issues or PRs.
## Development
`uv run pytest -q`, `uv run ruff check .`, and `uv run bandit -r harbor_aiops -ll` are local checks. Root handbook gates must pass before release.
TDQS
Scored across 39 tools
Tools target distinct Harbor resources, but the singular/plural pairs (harbor_project vs harbor_projects, harbor_replication_policy vs harbor_replication_policies, harbor_replication_execution vs harbor_replication_executions, harbor_retention_executions vs harbor_retention_tasks) plus the log/metric variants create easy misselection traps. Descriptions do carry the distinguishing detail, but an agent must read them carefully rather than pattern-match on the name.
Nearly all tools use a consistent harbor_<noun> snake_case convention with singular for get-one and plural for list, which is readable and predictable. The deviations are undo_list/undo_apply (outside the harbor_ namespace and verb-first) and harbor_diagnose, which are minor but noticeable.
39 tools is heavy for a single server and pushes well past the comfortable 3-15 range; several near-duplicates (harbor_scan_all_metrics vs harbor_scheduled_scan_metrics, three separate replication/retention log tools, harbor_diagnose overlapping the probes it correlates) inflate the surface. Each maps to a real Harbor endpoint, but the set is broad enough to burden tool selection.
Read/diagnostic coverage of the registry is strong — projects, repos, artifacts, tags, scans, quotas, GC, replication, retention, health and audit logs are all reachable. Write coverage is thin: only scan_artifact, create_tag and delete_tag mutate state, so project/repository/artifact/policy lifecycle operations and credential or quota management are notable gaps.