MCP server for Harbor container registry management and API access
Harbor MCP Server provides 12 well-named, read-focused tools for querying and managing a Harbor container registry. Tools follow verb_noun naming conventions consistently (get-, list-, search-, update-). However, the server has significant gaps in parameter descriptions, missing output schema documentation, and weak error handling. Parameter descriptions exist but are often minimal (10-30 chars). Most tools lack detailed guidance on when to use them or what they return. The one destructive tool (update-configurations) includes a confirmation parameter, which is good practice, but error recovery guidance is missing across all tools. No tool annotations (readOnlyHint/destructiveHint) are present despite clear READ_ONLY vs DESTRUCTIVE classifications in the metadata. The server does not implement idempotency or pagination best practices for list operations beyond basic limit/offset.
Get Harbor system configurations (admin only).
Get the health status of the Harbor instance.
Get a specific project.
Get a summary of a project.
Get the statistic information about projects and repositories.
Get system volume info (total/free size).
List members of a project.
Missing output schema documentation. No tool explicitly documents what fields are returned in responses. LLMs cannot plan downstream tool calls or extract relevant data without knowing response structure. Violates pattern:tool and pattern:response-shaper.
Minimal parameter descriptions. Most parameters have descriptions under 30 characters (e.g., 'The page number to retrieve.' for page, 'The project key (2-10 uppercase letters)' is missing). Descriptions should explain WHAT the parameter controls, WHY it matters, and provide format/constraint guidance. Baseline for A+ tools is 72 chars average.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
List projects with optional filters and pagination.
List storage quotas for projects.
List repositories within a specific project, with optional filtering and pagination.
Search for projects and repositories by name. Returns matching projects and repositories.
Update Harbor system configurations (admin only, confirmation required). ⚠️ WARNING: This action can heavily impact the Harbor server. The AI will always ask for explicit user confirmation before proceeding. Only use this if you are an admin and fully understand the consequences.
Missing tool annotations. The server metadata identifies tools as READ_ONLY or DESTRUCTIVE, but these are never declared in the actual tool registration. MCP 2026-07-28 supports readOnlyHint, destructiveHint, and idempotentHint. Without them, LLMs cannot automatically determine safety profiles and may misplan retries.
No error handling guidance. When API calls fail (401 auth, 404 not found, 500 server error), the tools return null or a generic failure message. LLMs receive no guidance on whether to retry, ask the user, or try an alternative approach. Violates pattern:recovery-guide.
Pagination inconsistency and no result limits enforced. list-projects, list-project-members, list-repositories-in-project, and list-quotas accept page/page_size but do not document max results or enforce caps. Returning 1000s of records can exhaust context windows. Baseline is to cap at 20-50 and offer next_cursor or total_count.
Parameter naming ambiguity: 'project_name_or_id' accepts two types but lacks guidance on which is preferred or how the tool disambiguates. Baseline pattern:tool-description requires type suffixes: 'project_id' and 'project_name' as separate optional params, or explicit resolution logic documented.
update-configurations requires explicit confirmation=true but lacks dry-run capability. Agents cannot preview changes before executing. For high-risk operations, a dry-run or detailed change summary response is recommended by pattern:confirmation-request.
No tool dependency hints or chaining guidance. For example, search() might return repositories but doesn't explain which tools to call next, or whether a user can directly pass the result to list-repositories-in-project. Missing pattern:tool-chain context.