v0.1.0

agentregistry

a vendor-neutral registry for AI agents, skills, and MCP servers


agents skills mcp-servers

$ agentctl server start

The Problem

  • AI agents are being built everywhere — but there's no standard way to register, discover, or trust them
  • Container registries store bytes — they don't know what models an agent uses, whether it's been safety-tested, or what it depends on
  • No supply chain visibility for AI artifacts — what's the BOM? Has it been evaluated? Who approved it?

What the Agent Registry Is

A metadata store that sits alongside OCI registries as a governance and discovery layer
Stores structured metadata about agents, skills, and MCP servers — not the binaries themselves
Accepts evaluation signals from any external tool (Garak, eval-hub, lm-eval-harness, custom CI)
Enforces a promotion lifecycle: draft → evaluated → approved → published

Three Artifact Kinds

Agent

  • Autonomous AI system with its own runtime
  • Declares models, tools, skills, orchestration
  • Has a container image in OCI

Skill

  • Prompt-based capability, no runtime
  • Consumed by agents or AI IDEs
  • Declares tool requirements, not concrete tools

MCP Server

  • Model Context Protocol server
  • Exposes tools, resources, prompts
  • Declares transport (stdio, HTTP, SSE)

All three share:
identity, versioning, promotion lifecycle, eval records, BOM

User Journey


You build an agent        agentctl does the rest            Others find it
──────────────────        ────────────────────              ──────────────

docker push image    ──>  agentctl init --path .            agentctl search "k8s"
                          (LLM reads your code,             agentctl inspect ...
                           generates manifest)              agentctl deps ...
                                                            agentctl get ...
                     ──>  agentctl push agents m.yaml              ↓
                          (draft — private, mutable)        docker pull + deploy

                     ──>  agentctl eval attach ...
                          (external tools submit results)

                     ──>  agentctl promote --to evaluated   Content locks here.
                     ──>  agentctl promote --to approved
                     ──>  agentctl promote --to published   Now discoverable.

Step 1: Generate Manifest

LLM reads your source code and generates the full YAML. No manual writing.


agentctl init --path ./my-agent \
    --image ghcr.io/acme/cluster-doctor:1.0.0 \
    -o manifest.yaml

Supports any LLM provider:

Anthropic OpenAI Ollama vLLM Any OpenAI-compatible

Step 2: Push & Evaluate


# Register the artifact (lands in draft)
agentctl push agents manifest.yaml
  

# External tools submit eval records (optional)
agentctl eval attach agents acme/cluster-doctor 1.0.0 \
    --category safety --provider garak \
    --benchmark toxicity --score 0.96

agentctl eval attach agents acme/cluster-doctor 1.0.0 \
    --category functional --provider eval-hub \
    --benchmark accuracy --score 0.88

The registry stores eval records. It does not run evaluations or compute trust scores.

Step 3: Promote

draft → evaluated → approved → published → deprecated → archived 

agentctl promote agents acme/cluster-doctor 1.0.0 --to evaluated
agentctl promote agents acme/cluster-doctor 1.0.0 --to approved
agentctl promote agents acme/cluster-doctor 1.0.0 --to published

Content becomes immutable after evaluated. What was evaluated is what gets shipped.

Step 4: Inspect


$ agentctl inspect agents acme/cluster-doctor 1.0.0

agent acme/cluster-doctor@1.0.0
  Status:    published
  Title:     Cluster Doctor
  Published: 2026-02-20T09:24:16Z

Eval Records: 3
  functional     1 record(s)
  safety         1 record(s)
  red-team       1 record(s)
  Average score: 0.92

Promotion History:
  draft → evaluated   — 3 evals pass
  evaluated → approved — Reviewed by platform team lead
  approved → published — Ready for production

Dependency Graph (from BOM)


$ agentctl deps agents acme/cluster-doctor 1.0.0

agent acme/cluster-doctor@1.0.0
  |- mcp-server acme/kubernetes-mcp@2.0.0 [resolved]
  |- mcp-server acme/prometheus-mcp@>=1.0.0 [UNRESOLVED]
  |- skill acme/k8s-troubleshooting@1.0.0 [resolved]
  |- model claude-sonnet-4@anthropic [resolved]

The BOM captures the full dependency graph:

Agents declare models, tools (MCP servers), skills, prompts, orchestration
Skills declare tool requirements (abstract, not tied to specific MCP servers)
MCP Servers declare runtime dependencies, external services

Architecture

agentctl CLI
Thin HTTP client. init, push, list, promote, eval, inspect, search, deps
External Tools
Garak, eval-hub, lm-eval-harness, TrustyAI, custom CI
Consumers
Agent runtimes, AI IDEs, CI/CD
UI — embedded HTML catalog
REST API — Chi router, /api/v1
Service — state machine, BOM resolution
Store Interface — SQLite (PoC) / Postgres
OCI Registries — ghcr.io, quay.io (content)

Design Principles

  • Metadata, not payloads — binary content stays in OCI registries
  • Evals are external signals — the registry stores them, doesn't compute trust
  • Promotion is a state machine — no hardcoded gates, policy layers add externally
  • CLI is a thin client — all logic server-side, any entry point behaves identically
  • Store is swappable — SQLite for PoC, Postgres for production
  • Manifest generation is LLM-powered — zero YAML writing for developers

What's Next

  • Trust scoring as a pluggable external service (TrustyAI integration)
  • Configurable promotion gates (webhook-based policy engine)
  • OCI registry integration (push + pull content from the registry)
  • Federation (peer discovery, cross-registry search, sync)
  • Authentication and RBAC
  • Postgres backend for production

demo



./scripts/demo.sh

UI → http://localhost:8080
API → http://localhost:8080/api/v1

Agent Registry