harbor-mcp

An MCP server for the Harbor hub. It exposes your evaluation jobs, trials, uploads, and published packages as tools an agent (Claude Code, etc.) can call directly, so you can ask "did my upload work?" or "what was the mean reward on job X?" without leaving the chat.

It wraps Harbor's own async client classes (HubClient, UploadDB, RegistryDB, Uploader, Downloader, Publisher), so there is no separate API layer to maintain. Harbor reads HARBOR_API_KEY and handles token exchange itself.

Setup

uv sync
cp .env.example .env      # then set HARBOR_API_KEY

Mint a key with harbor auth login (it stores one in ~/.harbor/credentials.json) and put it in .env:

HARBOR_API_KEY=sk-harbor-...

The repo ships a .mcp.json that Claude Code auto-discovers when started from this directory. It sources .env before launching, so your key never lives in the config. Verify the connection by asking the agent to call whoami.

Related MCP server: multivon-mcp

Tools

Read tools work with any valid HARBOR_API_KEY. Write tools are gated (see below).

Write gating

Every write tool refuses unless HARBOR_MCP_ENABLE_WRITES=true in the server environment. delete_job additionally requires confirm=true per call, which the agent should pass only after you explicitly approve deleting a specific job. This keeps read-only use the safe default.

Testing

HARBOR_TEST_ENV selects where harbor runs the fixture job: docker (default) or modal. Modal needs its own credentials (modal token new) and the modal extra (uv sync --dev --extra modal), which pulls in harbor's modal support; the base install omits it. The integration and e2e tiers are deterministic (no agent decisions), so they gate PRs without spending on model calls; the evals/ agent rollouts run separately once tool use is proven at the lower tiers.

The harbor dependency is pinned exactly because this server imports Harbor internals, which are not a stable public API. Bump it deliberately.