The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MISSING listing page.
MISSING is a product runtime for agents that need a capability they do not currently have.
Instead of hallucinating support or stopping at “I cannot do that”, an agent can ask MISSING to discover an existing replay-verified capability, execute it through a verified provider recipe, or durably record the unresolved demand so the trusted acquisition loop can search for new supply.
The long-term product loop is:
MISSING currently includes:
Historical experiments and formal operational gates remain in the repository as evidence, but they are no longer the product description.
Run the remote product runtime:
Primary surfaces include:
GET / — public product landing and connection guide;POST /mcp — MCP Streamable HTTP;GET /.well-known/agent-card.json — A2A Agent Card;POST / — A2A JSON-RPC;POST /v1/agent/resolve — agent-native paid resolution path when payments are enabled;GET /livez, /readyz, /healthz — operational state.Local stdio MCP remains available with:
Human-readable landing:
Canonical MCP endpoint:
A2A Agent Card:
Canonical paid execution endpoint:
The anonymous MCP exposes exactly four product tools:
list_verified_capabilities — inspect the complete replay-verified catalog and example inputs.search_verified_capabilities — find a verified capability from a natural-language task description.record_missing_capability_demand — persist an unresolved capability need when no verified match exists.resolve_capability — prepare paid execution for an exact verified capability.Discovery and catalog inspection are free. resolve_capability does not execute a provider inside MCP and does not charge the caller. It returns a payment_required handoff containing the current price, exact request body, canonical /v1/agent/resolve endpoint, and recovery-safe x402 instructions.
The subsequent HTTP x402 flow performs provider execution and settlement. Agents should preserve the exact request body and exact PAYMENT-SIGNATURE for recovery and should not create a second authorization for a payment already associated with a known transaction.
MISSING is published in the official MCP Registry as:
Smithery public server:
Smithery-hosted MCP gateway:
MISSING is also indexed by Glama from its public MCP/Registry surface.
Third-party MCP directories should point to the existing remote Streamable HTTP endpoint rather than deploy or proxy a second MISSING runtime. PUBLIC_DISTRIBUTION.md records the current Smithery and Glama distribution procedure.
The x402 402 Payment Required challenge advertises Bazaar discovery metadata while the durable payment, request-binding, settlement, finality, fencing, and recovery state machine remains unchanged.
MISSING does not treat discovery as proof.
A discovered provider lead cannot become executable merely because its documentation looks relevant. Automatic supply must pass deterministic compilation and replay-verification gates before promotion. Unknown demand remains unknown until that boundary is crossed.
Paid execution also fails closed around authoritative payment state. A successful provider call alone is not customer revenue; revenue is recognized only after settlement succeeds.
Kappa.5 and Operational Readiness 1–9 established the money/recovery and dependency-safety envelope. Real Agent Loop 1 then crossed the first live commercial boundary: production emitted GO_REAL_AGENT_PAID_CLOSED_LOOP from two distinct settled Base-mainnet payments reusing the same demand-derived promoted recipe with positive realized margin.
The current uncertainty is no longer whether the loop can happen once. It is whether MISSING can reproduce the commercial loop autonomously across independent capabilities:
Can at least two different external-agent demands each be selected by the trusted control plane, autonomously become replay-verified promoted supply, and each generate repeated positive-margin paid reuse?
REAL_AGENT_LOOP_2.md defines the preregistered proof contract.
Qualifying RAL2 promotions carry durable trusted-control-plane provenance (acquisition_path plus control_plane_run_id) so direct/manual promotion cannot be confused with autonomous acquisition evidence.
CI may validate the proof machinery but cannot claim the live commercial outcome. Only production ledgers plus real settled PostgreSQL rows on approved value networks may eventually emit:
GO_AUTONOMOUS_COMMERCIAL_REPLICATION
The repository keeps experimental evidence, product milestones, and operational-readiness gates separate so a passing synthetic/formal test cannot be mistaken for live market evidence.
The project began by testing whether an explicit fallback tool changes an agent's behavior when a needed capability is absent. Those preregistration-oriented experiments remain under experiments/ and the corresponding experiment source/workflow files.
They are retained as historical scientific evidence. Product code does not rewrite their provenance or promote newly discovered providers as experimental results.