Jesse Williams · July 8, 2026

Why MCP servers and agent skills need an enterprise registry

Interested in seeing the video demo for this tutorial? Click here: https://youtu.be/mrTzWKbYnD0

MCP servers and agent skills are already moving through teams the way shell scripts used to move: a GitHub link, a copied folder, a zip in Slack, or a note in chat that says "drop this into your agent directory."

That is fine for one laptop. It is weak for production.

These components are not passive files. A skill can change how an agent handles a support ticket, fills a PDF, or responds during an incident. An MCP server can expose tools for files, APIs, databases, tickets, or internal systems. Once a component can affect what an agent does, it needs an approval path.

Teams need to know where a skill came from, which version was approved, whether it was scanned, whether it was signed, and whether the installed copy matches the approved artifact. If the install path is "copy this folder," those questions are hard to answer.

The problem with copied skills

Most agent components start small. A developer writes a PDF helper. A support engineer finds an MCP server for ticket lookup. A security team creates an incident-triage skill.

At first, the component is local. It has a SKILL.md, a prompt file, a config file, or a small server definition. Someone tests it and it works.

Then another person asks for it.

That is where the workflow breaks. The skill moves as a folder. The MCP server moves as a repo URL. Instructions move through chat. One teammate changes a prompt. Another installs an older copy. The team still has something useful, but no clean release path.

Teams already learned this lesson with containers, model weights, deployment scripts, and prompts: if something can change runtime behavior, it needs versioning, review, provenance, and rollback.

What the registry needs to do

A registry for agent components has to answer the questions that matter before a component is installed:

  • What is approved?
  • Who published it?
  • What changed between versions?
  • Did scans pass?
  • Is it signed?
  • Which policy allowed it?

A source repository can hold the working files. A governed registry gives teams the approved artifact developers should install.

It also fixes a common split-brain problem. Models end up in one registry, MCP servers stay on GitHub, skills move around as folders or zip files, and policies live somewhere else again. Once the pieces are scattered, the audit trail breaks. The team may know what was approved in theory, but not what was actually installed.

Where Jozu Hub fits

Jozu Hub is the governed catalog in this workflow. The Jozu MCP, Skills, and Agent Registry page frames Hub as a place to store, scan, sign, and govern AI artifacts, including MCP servers and agent skills.

For this article, the roles stay simple:

  • Jozu Hub is the registry and catalog layer.
  • KitOps packages the artifact.
  • Agent Guard evaluates policy at admission time and at runtime.

Each layer has one job:

create skill or MCP component
package it as a ModelKit
push it to Jozu Hub
approve the artifact
install the approved version
enforce admission and runtime policy with Agent Guard

KitOps v1.13 adds the install step

KitOps packages AI assets as OCI-based ModelKits. That already works well for agent skills, which are often folders with SKILL.md and supporting prompt files.

KitOps v1.13 adds the command that makes the install path cleaner:

kit unpack <modelkit> --as-skill

Instead of unpacking the skill to its original path and asking a developer to move it by hand, KitOps can install SKILL.md prompt layers as agent skills.

Now the path looks like this:

local skill folder -> ModelKit -> registry artifact -> approved install

The point is simpler. The approved path becomes easier than copying a folder.

It also matches how teams actually work. A registry workflow only matters if the last step is simple enough that developers will use it. kit unpack --as-skill is much easier to defend than "pull this artifact, unpack it, and manually move files into the right agent directory."

Why the packaging layer matters

Using a ModelKit here is not just about putting files in a tarball with a nicer name. OCI packaging gives the team something they can tag, inspect, sign, scan, store in existing registries, and move through familiar promotion flows.

That matters because agent components rarely live alone. A useful skill often depends on prompt files, small configs, sample inputs, or related docs that explain how it should be used. If those pieces move separately, the artifact drifts. One developer installs the right folder but the wrong prompt. Another gets the updated prompt but not the matching config. The registry may have one version while laptops keep running another.

Packaging the component as a ModelKit gives the team a release unit. That is the real handoff point. Review happens against the artifact that will actually be installed, not against a vague promise that somebody copied the right files into the right place.

Demo setup: a small PDF helper skill

For the demo, use a small local skill called pdf.

Project layout:

pdf-helper-demo/
├── Kitfile
├── pdf/
│   ├── SKILL.md
│   └── prompt.txt
├── docs/
│   └── registration_form.pdf
├── data/
│   └── attendee_info.txt
└── opencode.json

[Visualization: local file tree for pdf-helper-demo/, with pdf/SKILL.md highlighted.]

The pdf/SKILL.md file defines the component:

---
name: pdf
description: Use this component to fill, read, merge, or create PDF files.
version: 0.1.0
license: MIT
compatibility: OpenCode and other agents that read local SKILL.md components
---

The Kitfile includes that folder under prompts::

prompts:
  - name: pdf
    path: pdf
    description: Use this component to fill, read, merge, or create PDF files.

This is the important part. The local skill is now part of the ModelKit package definition.

[Visualization: pdf-helper-demo/Kitfile with the prompts: block highlighted.]

The next step is to package it, push it through the registry workflow, and install it into a clean agent environment with kit unpack --as-skill.

Package the skill as a ModelKit

From the parent directory, package the demo:

kit pack pdf-helper-demo -t pdf-helper-demo:v1

At this point, the PDF skill is part of a tagged ModelKit. The team now has a specific version to review, push, install, compare, or roll back.

In a production workflow, the next step is to push that artifact to Jozu Hub:

kit push pdf-helper-demo:v1 jozu.ml/<namespace>/pdf-helper-demo:v1

This is where the registry value shows up. The approved artifact can be inspected, scanned, signed, and pulled through the normal artifact path. The full packaging and push workflow belongs in the official KitOps and Jozu docs. The blog only needs the short version and the result.

[Visualization: Jozu Hub artifact page for pdf-helper-demo:v1, showing contents, version, or scan/signing state.]

Install the approved skill

Now move to a clean project directory and install the skill from the ModelKit. According to the KitOps CLI docs, kit unpack first checks local storage and then falls back to the remote registry if needed, so this works as both an install step and a fetch step.

For a generic agent install, KitOps v1.13 supports:

kit unpack jozu.ml/<namespace>/pdf-helper-demo:v1 --as-skill

For a Codex project-scoped install, use:

kit unpack pdf-helper-demo:v1 --as-skill=codex -d ./clean-room

The result is a normal agent skill directory:

In a real Codex project, that means the skill ends up under:

.agents/skills/pdf

The developer did not copy a random folder from a repo. They installed a skill from a versioned artifact that can be reviewed and governed before use. The full install walkthrough can point readers to the KitOps CLI docs instead of repeating every option in the article.

The operational change is small but real. When a teammate asks, "Which PDF skill are we using?", the answer can be a tag and an artifact record, not "whatever is in my .agents directory right now." When security asks what was reviewed, the answer can point to the same artifact that developers installed. When something breaks, rollback is an artifact choice, not a scavenger hunt across laptops.

Where policy enters the workflow

This is also the point where security gets a clean control surface.

If Jozu Hub and Agent Guard access are available, package an unsafe version of the skill and push it as its own artifact:

kit pack pdf-helper-demo -t pdf-helper-demo:unsafe
kit push pdf-helper-demo:unsafe jozu.ml/<namespace>/pdf-helper-demo:unsafe

Then package a clean version and push that separately:

kit pack pdf-helper-demo -t pdf-helper-demo:clean
kit push pdf-helper-demo:clean jozu.ml/<namespace>/pdf-helper-demo:clean

Now the team can make a policy decision against the artifact that would actually be installed. If scan or attestation policy marks the unsafe artifact as unapproved, Agent Guard can block it at admission time and runtime and allow the clean version instead.

If that full path is not available in the demo environment, use the simpler pattern from the public Agent Guard demo: sign the clean artifact, leave the unsafe one unsigned, and block unsigned or untrusted artifacts. The point is the same. Policy attaches to the packaged artifact, not to a folder someone copied by hand.

What this changes

The command is small:

kit unpack <modelkit> --as-skill

A skill can now move through the same path teams expect for other production artifacts:

create -> package -> scan -> sign -> approve -> install -> enforce

That gives platform and security teams a better control point. Developers still get a simple install command, but what they install is the approved artifact, not whichever folder was shared last.

This is the real value of keeping the story Jozu-first. KitOps makes the artifact portable. Jozu Hub makes it governable. Agent Guard makes the policy real in the environment where the agent runs.

Closing

MCP servers and agent skills are becoming deployable behavior. They should not move through screenshots, copied folders, or shared zips.

KitOps v1.13 gives teams a direct way to install a packaged skill into an agent environment. Jozu Hub gives that package a governed registry home. Agent Guard can enforce policy when the artifact moves toward execution.

That is the difference between "I copied a skill from somewhere" and "I installed the approved version from the registry."

Sources

Share this post