> ## Documentation Index
> Fetch the complete documentation index at: https://mwillaimission.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Manifest Registry: How to Register and Query Services

> How the Manifest Registry indexes agent-native services — manifest format, five manifest blocks, trust tiers, three query modes, and the ranking algorithm.

The AgentLedger Manifest Registry solves the discovery problem by giving agents a universal, machine-queryable index of agent-native services. Think of it as DNS, an app store, and a package registry combined — but designed from the ground up for agents rather than retrofitted from human-facing infrastructure. When your agent needs to find a service that can book a flight, process a payment, or sign a document, the Manifest Registry is where it looks.

## The agent manifest

Every registered service publishes a structured manifest at a standard well-known path:

```text theme={null}
/.well-known/agent-manifest.json
```

The manifest is divided into five blocks. Each block answers a specific question an agent needs answered before deciding whether to interact with a service.

### Identity block — who are you?

The identity block establishes the service's verifiable identity, including domain ownership and cryptographic signing key.

```json theme={null}
{
  "manifest_version": "1.0",
  "service_id": "uuid-v4-globally-unique",
  "name": "FlightBookerPro",
  "legal_entity": "FlightBookerPro Inc.",
  "domain": "flightbookerpro.com",
  "domain_verified": true,
  "public_key": "sha256:abc123...",
  "manifest_signature": "...",
  "last_updated": "2026-04-10T00:00:00Z"
}
```

### Capability block — what can you do?

The capability block describes each available action using ontology tags from the open AgentLedger capability vocabulary. Agents use these tags to find services by what they do, not just by name.

```json theme={null}
{
  "capabilities": [
    {
      "id": "book_flight",
      "description": "Books a one-way or round-trip flight given origin, destination, dates, and budget.",
      "ontology_tag": "travel.air.book",
      "input_schema": "https://...openapi#BookFlight",
      "output_schema": "https://...openapi#BookingConfirmation",
      "success_rate_30d": 0.97,
      "avg_latency_ms": 1200,
      "tested_by_registry": true
    }
  ]
}
```

### Economics block — what does it cost?

The economics block declares pricing in a machine-readable format so your agent can evaluate cost before committing to a transaction.

```json theme={null}
{
  "pricing": {
    "model": "per_transaction",
    "tiers": [
      { "name": "standard", "cost_usd": 0.85, "per": "transaction" },
      { "name": "volume", "cost_usd": 0.40, "per": "transaction", "min_volume": 1000 }
    ],
    "billing_method": "x402"
  }
}
```

### Context requirements block — what data do you need?

The context block lets agents understand what data a service requires and how sensitive that data is — before passing any user information.

```json theme={null}
{
  "context": {
    "required": [
      { "field": "user_budget_usd", "type": "number", "sensitivity": "financial" },
      { "field": "travel_dates", "type": "daterange", "sensitivity": "low" }
    ],
    "optional": [
      { "field": "passport_nationality", "type": "string", "sensitivity": "pii_high" }
    ],
    "data_retention_days": 0,
    "data_sharing": "none"
  }
}
```

### Operations block — can I rely on you?

The operations block exposes reliability data, rate limits, compliance certifications, and sandbox access so agents can make informed routing decisions.

```json theme={null}
{
  "operations": {
    "uptime_sla_percent": 99.9,
    "rate_limits": { "rpm": 100, "rpd": 10000 },
    "compliance_certifications": ["SOC2", "GDPR", "CCPA"],
    "sandbox_url": "https://sandbox.flightbookerpro.com"
  }
}
```

## Trust tiers

Not all registered services carry the same level of verification. The Manifest Registry assigns each service a trust tier based on how much evidence has been gathered about its identity and function.

| Tier                  | How achieved                               | Trust level                   |
| --------------------- | ------------------------------------------ | ----------------------------- |
| ⭐ Crawled             | Registry finds manifest at `/.well-known/` | Baseline, unverified          |
| ⭐⭐ Domain verified    | DNS TXT record confirms domain ownership   | Identity confirmed            |
| ⭐⭐⭐ Capability probed | Live synthetic transactions pass           | Identity + function confirmed |
| ⭐⭐⭐⭐ Ledger attested  | Full Trust Ledger attestation              | Maximum trust                 |

<Tip>
  Use the `trust_min` query parameter to filter results to services that meet a minimum trust score. For high-stakes actions like payments or document signing, require Ledger Attested (tier 4) services.
</Tip>

## Query interface

The registry exposes three query modes. Choose the one that fits your agent's integration pattern.

<Tabs>
  <Tab title="Structured API">
    Query by ontology tag, trust threshold, geography, and budget ceiling in a single GET request:

    ```http theme={null}
    GET /services?ontology=travel.air.book&trust_min=80&geo=US&budget_max=1.00
    ```

    Use this mode when your agent has a well-defined capability requirement and needs deterministic, filterable results.
  </Tab>

  <Tab title="Natural language">
    Pass a free-text query and let the registry resolve it to matching ontology tags:

    ```http theme={null}
    POST /search
    { "query": "Book a round-trip flight from Seattle to NYC under $600" }
    ```

    Use this mode when the user's intent arrives as natural language and you want the registry to handle intent-to-ontology mapping.
  </Tab>

  <Tab title="Ambient discovery">
    The agent extracts an entity name from user context, performs a registry lookup, and evaluates trust before interaction — with no explicit query from the orchestration layer.

    Use this mode for passive service resolution when the user references a service by name in conversation.
  </Tab>
</Tabs>

## Ranking algorithm

When a query returns multiple matching services, the registry ranks them using a weighted composite score:

```text theme={null}
SCORE = (Capability Match  × 0.35)
      + (Trust Score       × 0.25)
      + (Latency Score     × 0.15)
      + (Cost Efficiency   × 0.10)
      + (Reliability Score × 0.10)
      + (Context Fit       × 0.05)
```

Capability match carries the highest weight because a service that does exactly what you need is more valuable than one that is merely trustworthy or cheap. Trust score is the second-highest factor, reflecting that reliability without verifiability is insufficient for autonomous agent decisions.

<Note>
  The ranking algorithm uses live data. `success_rate_30d`, latency, and uptime metrics in each manifest are updated continuously by the registry's capability probing system — not self-reported by the service alone.
</Note>