One ability layer for AI agents

Ask for an outcome. Capability finds the ability.

Capability gives an AI one front door for what it needs to do. It prefers prepared connectors, MCP, OpenAPI, and native abilities first; when those run out, it can reach into existing software without forcing the application to adopt a second tool architecture.

MIT licensed · TypeScript · Capability 1.1 · stable 1.x public contract · remote MCP

terminal — bootstrap an agent
$ npx -y @wheresmycoleslaw/capability mcp-serve

agent I need an ability to analyze a failure plan
tool capability_search("failure frontier")
  → capability/failure-frontier

tool capability_inspect(...) 
  → effects: []
  → deterministic: true

The ability layer

Your agent should ask for what it needs — not care which integration mechanism provides it.

Capability resolves an outcome through prepared providers first, then falls back to existing software when the prepared ecosystem has no answer. The same authority and receipt model stays visible either way.

Discovery before installation

An agent can search inert capability contracts without importing arbitrary package code just to learn what the package does.

Authority is part of the contract

Filesystem, network, process, secrets, database, email, and Git effects are visible before execution instead of hidden behind a generic tool call.

Acquisition is not trust

Indexes locate abilities. The client still resolves an exact artifact, checks package identity and available provenance, and binds the executable back to the inspected manifest.

Execution leaves evidence

Plans, verification results, provenance, timing, outputs, and failures can be preserved as receipts rather than disappearing into an opaque agent run.

One protocol

Discovery is not trust. Trust is not authorization. Authorization is not isolation.

Capability keeps the boundaries separate, then connects them into one inspectable lifecycle.

01Discover
02Resolve
03Verify
04Acquire
05Inspect
06Authorize
07Execute
08Verify
09Receipt

MCP bootstrap bridge

One small tool surface opens the network.

The remote MCP bridge leads with one tool: capability_need. The agent states the outcome; Capability chooses the best available route. Expert discovery, Forge, metabolism, composition, and inspection tools remain available underneath.

https://sithix.com/api/capability/mcp
capability_need

Primary front door: state the outcome, prefer prepared providers, then fall back to the software world when necessary.

capability_search

Find a native executable ability the agent does not already have.

capability_search_world

Search native Capability indexes plus existing npm and GitHub software without pretending external search results are trusted code.

capability_mine_repository

Inspect a selected GitHub repository at an exact commit for evidence-backed useful abilities without executing repository code.

capability_forge_repository

Bind a selected npm-backed function or CLI to exact source/artifact evidence, generate a private Capability, and require Docker for its first execution.

capability_solve

Start with an outcome: search native abilities and existing software, mine promising repositories, and forge a defensible operation when needed.

capability_metabolize

Acquire an ability through a defensible execution substrate: native, npm/GitHub Forge, explicitly selected PyPI software, or an OCI image.

capability_compose

Synthesize an explicit multi-step intent from schema-compatible Capability contracts and preserve a receipt for every step.

capability_coverage

Report concrete software substrate coverage without inventing a percentage of all software.

capability_inspect

Read its inert contract and declared effects before code runs.

capability_execute

Verify, acquire, authorize, isolate, execute, and receipt it.

capability_probe_site

Ask a website whether it advertises Capability indexes.

capability_doctor

Check whether the environment can reach the network and isolate execution.

Don’t rewrite the world

Capability can now search software that already exists.

A useful project does not have to be rebuilt inside Capability. Native abilities remain first-class, while npm packages and GitHub repositories can be discovered as external candidates and adapted through sidecars, MCP imports, or OpenAPI contracts.

Search outside the registry

$ cap world "render html to video"

Results stay visibly separated: native Capability entries are executable contracts; external npm/GitHub matches are only candidates until a defensible adapter binds an exact operation and authority surface.

Bridge the software you already trust

$ cap npm-inspect some-package
$ cap bridge npm some-package ./some-package-cap --id vendor/ability --bin command
$ cap mcp-import node ./existing-server.mjs --namespace existing-server

The upstream project stays unchanged. Capability supplies the machine-readable contract, exact artifact binding, visible permissions, and execution boundary. Unknown effects remain explicitly opaque until audited.

Discovery is not trust. Finding an external project never grants it authority or turns it into a verified Capability by declaration.

Mine the repo itself

A GitHub repository no longer has to advertise Capability before an agent can understand what is useful inside it.

Capability can resolve an exact repository commit, inspect supported source files plus manifests, docs, tests, examples and routes, then emit evidence-backed candidate abilities without executing the repository. Mining discovers; Forge is the separate boundary that can make a selected operation executable.

From repository to candidate abilities

$ cap world "render video"
      ↓
GitHub repository candidate
      ↓
$ cap mine github owner/repo --query "render video"
      ↓
public/exported symbols + CLI + routes
      ↓
docs + tests + examples + effects
      ↓
evidence + confidence + coverage
      ↓
non-executable draft contracts

Inference never silently becomes trust

Every mined candidate remains executable: false and authority.complete: false. Missing evidence for filesystem, network, process, environment or other effects is never treated as proof that those effects are absent.

Before execution, a specific operation still has to cross a stronger boundary: a native contract, reviewed sidecar, MCP/OpenAPI import or other concrete adapter must bind the exact artifact and authority surface.

$ cap mine github sindresorhus/slugify --query slug

Capability 1.0

The architecture is stable. The coverage remains extensible.

1.0 is not a cosmetic version bump. It is the 1.x compatibility promise: build Capability-native software, hosts, indexes, or new execution-substrate binders against the public contracts without expecting the load-bearing architecture to be casually redesigned underneath you.

A real extension boundary

MetabolicBinder is now a stable 1.x extension contract. A conformant executable binding must identify its binder and substrate, preserve evidence, record truthful authority state, and resolve a mutable discovery locator to an exact immutable artifact before execution.

Unknown authority cannot disappear

If authority is incomplete, custom:external.opaque-effects remains explicit. The common registry rejects an incomplete binding that drops that uncertainty and refuses execution without explicit approval, even if a third-party binder forgets its own guard.

One receipt across future substrates

Every execution attempted through the 1.x metabolic registry gets a stable receipt containing binder/substrate identity, original locator, exact artifact, authority state, evidence, timing, isolation information, and any substrate-specific upstream receipt.

Conformance is executable

runProtocolConformance() tests the stable protocol contracts without network access. runBinderConformance() lets an independently authored WASM, Rust, JVM, .NET, native-binary, or future binder prove it fits the same public boundary without a project-specific patch to Capability core.

Capability 1.0 stabilizes the mechanism. It does not claim every software artifact already has a binder, that hashes prove safety, or that any one sandbox contains every hostile program. New substrate coverage can grow additively throughout 1.x without redefining what Capability is.

Software metabolism

An agent can acquire an ability that did not exist in its toolset when the request began.

Capability 1.0.0 can start from the outcome alone. It can reject a plausible-but-wrong native tool, search existing software, understand an untouched repository, bind a selected operation to an exact published artifact and source revision, generate a private Capability, execute its first run in Docker, and return a receipt.

No package name. No repo name. No prewired camelCase tool.

"Convert separated text to camel case."
        ↓
cap solve / capability_solve
        ↓
search native abilities
        ↓
reject text/normalize: plausible, but wrong intent
        ↓
search the existing software world
        ↓
find sindresorhus/camelcase
        ↓
mine the untouched GitHub repository
        ↓
discover the camelCase function
        ↓
bind camelcase@9.0.0 ↔ npm gitHead ↔ exact Git commit
        ↓
generate a private Capability sidecar
        ↓
custom:external.opaque-effects stays visible
        ↓
explicit approval + Docker first run
        ↓
"hello capability world"
        ↓
"helloCapabilityWorld"
        ↓
receipt

The request never named the software.

The released 1.0.0 smoke starts only with convert separated text to camel case. Capability discovers the unchanged third-party sindresorhus/camelcase project on its own, mines camelCase, and turns it into a usable ability during that run.

Discovery is allowed to be ambitious. Trust is not.

Lexical native search is gated by intent fit, source evidence is rebound to npm gitHead when available, forged operations remain authority-incomplete, and custom:external.opaque-effects forces explicit approval. First execution is Docker-only.

The upstream project never adopted Capability.

No fork, plugin, wrapper PR, or upstream code change was required. Capability generated its own private interface around software that already existed. Automatic Forge binders currently cover npm CLI entry points and root-callable JavaScript/TypeScript package exports; broader mined surfaces stay non-executable until a real binder exists.

$ cap solve "convert separated text to camel case" --input '{"args":["hello capability world"]}' --approve

→ discovered: sindresorhus/camelcase
→ forged: forged/sindresorhus-camelcase/camelcase
→ result: helloCapabilityWorld
→ receipt: succeeded

Metabolic coverage

One binder should unlock a class of software, not one project.

Capability 1.0 stabilizes acquisition by execution substrate. The reference runtime now has concrete boundaries for npm/Node, PyPI/Python, OCI images, MCP, OpenAPI, repository evidence, runtime composition, and machine-readable capability gaps.

PyPI / Python — exact wheel bytes

$ cap pypi-mine inflection --query "camelize text"
$ cap pypi-forge inflection --symbol camelize --execute '{"args":["hello_world"]}' --approve

→ wheel SHA256 verified
→ exact wheel stored
→ --no-index --no-deps
→ Docker network: none
→ HelloWorld

The automatic Python binder accepts non-yanked universal wheels, mines their source without importing the package, pins the exact verified wheel bytes and Python base-image digest, and executes without network access. Platform-specific wheels stay outside this binder until their platform can be bound explicitly.

OCI — the container is the artifact

$ cap oci-inspect busybox:1.36
→ busybox@sha256:…

$ cap oci-run busybox:1.36 echo capability-oci-ok --approve
→ immutable RepoDigest
→ network denied by default
→ capability-oci-ok

Capability resolves mutable tags to immutable image digests, then runs the digest with a read-only root filesystem, dropped capabilities, no-new-privileges and resource limits. Digest identity proves which bytes ran; it does not declare those bytes safe.

Composition — abilities from the space between tools

$ cap compose-intent "normalize text then slugify text"   --input '{"text":"  Hello   Capability World  "}'

text/normalize → text/slugify
→ hello-capability-world
→ receipt per step

The planner rejects known schema contradictions, synthesizes a composite manifest, unions the authority envelope, and keeps provenance and receipts at every execution boundary. Today intent-first composition auto-selects native indexed contracts; the lower-level primitives can accept external contracts from future binders.

Gaps — failure becomes the next software specification

$ cap gap "missing outcome" --out missing.json
$ cap build-gap missing.json ./missing-capability

need → search → compose → unresolved
→ machine-readable gap
→ buildable Capability project

An unresolved request can preserve its desired contract, authority ceiling, verification requirements and search evidence. A human or coding agent gets a normal Capability project containing that exact gap instead of a vague “tool not found” dead end.

Capability reports metabolic coverage as concrete supported substrate families. It does not claim a fake percentage of “all software,” and it does not treat artifact identity as semantic trust.

The web can advertise abilities

A predictable place for an agent to ask: what can this site do?

Participating domains can publish a small locator at /.well-known/capabilities. The document points to one or more federated indexes and may advertise an MCP bootstrap path. It does not bypass package verification or execution policy.

GET https://example.com/.well-known/capabilities

{
  "capabilityDiscoveryVersion": "0.1",
  "indexes": ["https://example.com/capability-index.json"],
  "mcp": [{
    "transport": "stdio",
    "command": "npx",
    "args": ["-y", "@vendor/package", "mcp-serve"]
  }]
}

This site publishes its own descriptor at /.well-known/capabilities.

Agent-native primitives

The seed network is not just a directory of wrapper functions.

Capability includes primitives for problems created by dynamically extensible autonomous software itself: authority, failure, substitution, evolution, reproducibility, composition, and selection.

Authority Envelope

Expose excess authority across a proposed agent plan before execution.

Failure Frontier

Find the first irreversible mutation, retry-safe prefix, approvals, and compensation coverage.

Safe Substitution Certificate

Decide whether one ability can replace another without expanding authority or weakening the machine-readable contract.

Contract Evolution Gate

Evaluate upgrades by authority and behavioral guarantees in addition to ordinary API compatibility.

Receipt Drift

Detect behavioral, authority, verification, and supply-chain drift across executions.

Dominance Resolver

Remove strictly inferior interchangeable abilities while preserving real tradeoffs rather than hiding them inside one score.

Build one

A developer should not need to study the runtime before contributing an ability.

$ npx @wheresmycoleslaw/capability create my-capability --id my-domain/my-ability
$ cd my-capability && npm install
$ npm test
$ npm run readiness
$ npm run novelty

The generated project includes strict TypeScript, inert metadata, manifest-drift tests, packaging checks, CI, tokenless trusted-publishing setup, registry-entry generation, and novelty analysis against the reachable network.

Status

The machinery works. The standard now needs independent participants.

Capability 1.0.0 proves released-package metabolism across npm/GitHub Forge, exact verified PyPI wheel execution, immutable OCI images, runtime composition, and the unresolved-gap-to-buildable-project loop. The next proof is independent people using these boundaries against software and infrastructure we do not control.