Delivery
How an active skill actually reaches an agent — the MCP pull tier, the OpenClaw push tier, the active-only gate on both, and how the bundled usage skill differs.
Authoring and approving a skill makes it active. Delivery is the separate
question of how that active skill gets in front of a running agent. There are
two tiers, with very different reliability — and both serve active-only once
Skill Factory is enabled.
Tier 1 — MCP pull
The agent fetches skills itself through the memclaw_doc tool:
op=search collection='skills'— semantic search over skillsummaryembeddings.op=query collection='skills'— structured (filter-based) retrieval over the collection, no embedding needed.op=read collection='skills' doc_id=<slug>— fetch a specific skill.
When skills_factory.enabled is on, the server enforces active-only on this
path, with no way for the caller to widen it:
readof a non-active skill → 404 (no existence leak).query/search→status='active'is forced; a caller-suppliedstatusis rejected (422).- Filtering respects tenant ownership (no cross-tenant bleed).
This tier is probabilistic: the agent has to decide to look, and search has to surface the right skill. Good for discovery; not a guarantee the agent will use a given skill.
Tier 2 — OpenClaw push
The OpenClaw plugin reconciler removes the discovery step. On each heartbeat it calls:
POST /api/v1/skills/installable { tenant_id, fleet_id?, limit }and writes every returned skill to the node's managed skills directory as a
SKILL.md, then (optionally) registers that directory on OpenClaw's skill load
path. The agent sees the skill in its skill list without searching for it —
reliable delivery. Details and configuration in OpenClaw
plugin.
The endpoint is deliberately narrow and fail-safe:
- The collection is fixed to
skillsand the filter is server-decided — a harness cannot ask for non-active skills. - Opted-in tenant →
status='active'only. Not opted in → every visible skill (byte-identical to the legacy reconcile — the merge-day no-op). - If the opt-in flag can't be read, the endpoint returns 503 rather than fall back to returning everything — an outage can never push a non-active skill.
Both tiers deliver promptly to the node, but an agent session already running keeps its cached skill list until a fresh session starts. A newly-active skill reaches new sessions immediately and existing ones on their next restart.
Which tier do I get?
| MCP pull | OpenClaw push | |
|---|---|---|
| Who fetches | the agent, on demand | the plugin reconciler, every heartbeat |
| Reliability | probabilistic (must search + choose) | reliable (on disk + in skill list) |
| Requires | any MCP client | the OpenClaw plugin installed on the node |
| Active-only gate | op=read/query/search filter | /skills/installable server filter |
If your agents run under OpenClaw, the push tier is the dependable path; the pull tier is always available to any MCP client as a discovery surface.
Not the same thing: the bundled usage skill
Don't confuse Skill Factory delivery with the bundled usage skill installer:
GET /api/v1/install-skillreturns a one-liner that installs MemClaw's own usage guide (thememclawskill, orcompany-brain) into Claude Code / Codex.GET /api/v1/skill/{name}serves those allowlisted static skills.
Those teach an agent how to use MemClaw; they are not catalog skills flowing through the Skill Factory lifecycle. See the OSS README "Install the skill" section for that installer.
Where to look in the source
- Push endpoint (
/skills/installable) + active-only gate:core-api/src/core_api/routes/documents.py - MCP pull filter (
memclaw_docoverskills):core-api/src/core_api/mcp_server.py - Reconciler (push):
plugin/src/reconcile-skills.ts
Skills Inbox
The human-in-the-loop review queue for staged skills — the card an operator sees, the five actions, and how to recover a quarantined skill.
OpenClaw plugin delivery
How the OpenClaw plugin's reconciler pushes active skills onto a node — managed vs shared target dirs, the ownership marker, registering on the load path, and per-node observability.