v0.1 spec · published Mar 2026

A phone book
for your AIs.

You built five local services last month. Your new AI session doesn't know any of them exist. ASMP is the inventory — three files, one localhost API, every session starts there instead of a scavenger hunt.

IHost ProfileWhat this device can do
IIService ManifestWritten by the agent
IIIRegistrationDiscover & extend

See it

Ask once.
Find in 250ms.

You ask your AI a vague question. It checks the phone book instead of digging through old setups.


Ship with software

Every repo carries
its own asmp.yaml.

No manual filing. Put a manifest at the repo root — the registry scans your machine every five minutes and introduces new services to every agent session.

1

Ship it

Add asmp.yaml beside your code. List real capabilities.provides values.

2

Scan finds it

POST /discover/scan walks configured paths and syncs into ~/.asmp/services/.

3

Agents meet it

Running services can announce on start. Agents query by capability — not by grepping ports.


Get started

One command.
Or paste to your agent.

One curl sets up ~/.asmp/, a registry on :7700, and a reference server you can swap out later.

terminal
# bootstrap ASMP on this machine curl -fsSL https://raw.githubusercontent.com/agent-service-manifest-protocol/agentservicemanifest.io/main/scripts/bootstrap-asmp.sh | bash

What this is

One device. Many agents.
A shared contract.

MCP lists tools. A2A lists agents. ASMP lists what's installed on this machine — and how to register something new. Same stack, different question.

I

Host Profile

One file describing this device: OS, hardware, what it can do, and the rules for registering services.

II

Service Manifest

One YAML per service, written by whatever built it. Name, port, capabilities, how to start it.

III

Registration

Localhost API on :7700. Register, search by capability, attach mods — the inventory every session reads.


Stack

Below MCP
and A2A.

Three protocols. Three questions. Use them together.

Tool layerMCP
"What tools can I use?"
Agent layerA2A / ACP
"What agents can I talk to?"
Host layerASMP
"What services run here, and how do I register new ones?"
ASMP doesn't replace systemd, launchd, Docker Compose, or Kubernetes. It's the file those systems can read — mapped to plists · units · compose files.

I
Part One · Host Profile

What this device is, and what it can do.

One YAML file at a fixed path: hardware, capabilities, where manifests live, and who gets to register services.

  • ~/.asmp/host.yaml — personal scope
  • /etc/hmp/host.yaml — system scope
  • policy decides who can register, port ranges, and limits
~/.asmp/host.yaml
asmp: "0.1" kind: host host_id: "daniels-macbook-2026" device_class: personal_compute os: name: macOS version: "15.3.1" arch: arm64 hardware: cores: 12 ram_gb: 36 gpu: "Apple M4 Pro" capabilities: - files.local - email.local - calendar.local - networking - containers - gpu.inference registry: path: ~/.asmp/services/ api: http://127.0.0.1:7700 policy: agent_can_register: true requires_approval: false max_services: 100 allowed_ports: "7000-9999" data_sensitivity_default: medium

II
~/.asmp/services/inbox-triage.yaml
# written by the agent that built it asmp: "0.1" kind: service identity: name: inbox-triage author: "agent://reeves/mail" version: "1.2.0" runtime: exec: "python -m inbox_triage" restart: on-failure network: port: 7821 bind: 127.0.0.1 capabilities: - email.local - files.local mods: - name: spam-scorer author: "agent://eidos/filter" observability: log_dir: ~/.asmp/logs/inbox-triage display: label: "Inbox Triage" icon: mail
Part Two · Service Manifest

One file per service. Authored by the agent.

Each file in ~/.asmp/services/. Short on purpose — enough to wire ports and restarts, not enough to fill a wiki.

  • Identity, runtime, network — name, how to start it, which port
  • Capabilities — what host resources it uses
  • Observability & display — logs and a human-readable label
  • Mods — another agent can extend a service it didn't build

III
Part Three · Registration Protocol

A localhost API to register, discover, and extend.

HTTP on 127.0.0.1:7700 only. List services, search by capability, attach mods, remove cleanly. Nothing past localhost.

POST/servicesRegister a new service
GET/servicesList all registered
GET/services/{name}Manifest + runtime state
PATCH/services/{name}Update a manifest
DEL/services/{name}Deregister a service
GET/hostGet the host profile
GET/capabilitiesQuery by capability
POST/services/{name}/modsAttach a mod

Discovery flow

Inventory first.
Not a scavenger hunt.

The agent doesn't guess ports or grep your repos. It asks the registry what's already here — by name or capability — and moves on.

i

Ask

Vague question in the terminal — "use whatever handles email."

ii

Query

GET /capabilities?provides=email.local on :7700.

iii

Match

Registry returns manifests — names, ports, capabilities.

iv

Invoke

Agent calls the right service. No port lottery.

v

Next session

Same inventory. No rediscovery. ~250ms, not ~45s.


Design principles

Six constraints
we kept.

I

Agents write manifests

Whoever builds the service declares it. The inventory outlives the session.

II

Host-centric

Tied to a device — your Mac, your homelab, your box.

III

Runtime-neutral

launchd, systemd, Docker, k8s — ASMP is the input, not the runner.

IV

Works with MCP & A2A

Tools above, agents beside, inventory underneath.

V

Small surface area

Every field does a job. No manifest the size of a novel.

VI

Mods are first-class

Services can be extended by agents that didn't build them.


Next steps

What's
next.

Spec

JSON Schema

Formalize the manifest schema for validation and tooling.

Implementation

Reference server

The registration API server in Python, bound to localhost.

Migration

Reeves migration

Convert 35+ existing services to ASMP manifests.

Open source

Eidos package

Extract as a framework-agnostic, open-source package.

Interop

MCP bridge

Auto-generate MCP tool manifests from ASMP service capabilities.