Signed Tool Manifests

The pricing server declares a priced tool and signs it once

You publish quote on your pricing server at USD 0.01 a call, the price the outside buyer's grant in Quickstart part 2 pays. The native service builder declares the tool, its schemas, and its price in one place, and produces the manifest.

pub fn build_service(public_key_hex: String) -> Result<NativeChioService, ManifestError> {
    NativeChioServiceBuilder::new("pricing", public_key_hex)
        .server_name("Larkfield Pricing")
        .server_version("1.0.0")
        .tool(
            NativeTool::new(
                "quote",
                "Quote a SKU at a discount, rounded half up to the cent",
                serde_json::json!({
                    "type": "object",
                    "properties": {
                        "sku": { "type": "string" },
                        "percent": { "type": "number", "minimum": 0, "maximum": 100 }
                    },
                    "required": ["sku", "percent"]
                }),
            )
            .read_only()
            .per_invocation_price(1, "USD")
            .latency_hint(LatencyHint::Instant),
            // pricing.rs: parses sku and percent, returns the quote as JSON
            |arguments| pricing::quote_json(&arguments),
        )
        .build()
}

per_invocation_price(1, "USD") is 1 minor unit, one cent: MonetaryAmount counts whole minor units, and a dollar is 100 of them. The example then signs the manifest with the server keypair. On the kernel side, admission calls verify_manifest with the registered public key and registers the server; the tools keep their schemas, pricing, and side-effect flags.

use chio_manifest::verify_manifest;

// signed: &SignedManifest from the application's registration transport.
// registered_key: &PublicKey from operator-owned trust configuration.
verify_manifest(signed, registered_key)?;

// connection: Box<dyn ToolServerConnection> for the admitted server.
kernel.register_tool_server(connection);

The unit of signing is the whole manifest. Adding or removing a tool, changing a price, or bumping a version needs a fresh signature, and the kernel rejects a manifest whose body differs from the signed bytes.

A known key must sign every tool and every price the kernel registers

The signature closes two attacks on a tool catalog.

• Unauthorized tool advertisement. A compromised server could add an entry that looks benign and route its invocations to a malicious backend. The kernel admits a manifest only under a known key, so the attacker would need both the binary and its signing key.
• Price changes after the fact. Pricing lives inside the signed manifest. An operator who set a budget against a published price knows that price changes only with a fresh signature, and verifying the signature exposes any drift.

A valid signature authenticates the catalog the kernel registers against. Each call to a registered tool is still authorized by the caller's capability token at runtime.

Read more in Capabilities.

Registration runs five checks, and any failure refuses the whole manifest

For each registration, the kernel walks the same path, in order.

1. Read. Take the SignedManifest from the registration payload.
2. Validate. Run validate_manifest: schema, identity fields, a non-empty tool list, unique tool names, a unique server-tool allowlist.
3. Verify. Check the Ed25519 signature against the public key registered for that server_id.
4. Cross-check. Confirm the manifest's own public_key field matches the verifying key.
5. Register. Record the tools, schemas, pricing, and side-effect flags.

A bad signature means tampering or the wrong signing key. No tool from a refused manifest registers, so a producer fixes the error and signs again.

Declared permissions tell the operator what the host must allow

A server can declare what it needs from its sandbox in required_permissions: the paths it reads and writes, the network hosts it reaches, and the environment variables it reads. The operator sees the request before registration and either grants it or refuses to admit the manifest. The host that runs the server enforces the grant.

Provider-native server tools, such as Anthropic's computer use, bash, and text editor, carry a larger trust boundary than ordinary tools. The manifest allowlists them by name in server_tools, and an absent entry is refused. Versioned wire names such as bash_20241022 map to their category, so a provider's version bump stays behind the same allowlist entry.

Read more in The assurance model.

A metered tool advertises a batch it can price in whole cents

You sell an outside buyer read access to your order history through the orders server's sql tool, billed by rows returned. The billing unit is a batch of a thousand rows, and the advertised unit_price is 100 cents per batch. The field names are the manifest's own, and the keys are shortened.

{
  "manifest": {
    "schema": "chio.manifest.v1",
    "server_id": "orders",
    "name": "Larkfield Orders",
    "description": "Read-only SQL over the orders, skus, and customers tables",
    "version": "1.0.0",
    "tools": [
      {
        "name": "sql",
        "description": "Run one read-only query and return its rows",
        "input_schema": {
          "type": "object",
          "properties": {
            "query": { "type": "string" },
            "max_rows": { "type": "integer" }
          },
          "required": ["query"]
        },
        "output_schema": null,
        "pricing": {
          "pricing_model": "per_unit",
          "unit_price": { "units": 100, "currency": "USD" },
          "billing_unit": "1000-rows"
        },
        "has_side_effects": false,
        "latency_hint": "fast"
      }
    ],
    "required_permissions": null,
    "public_key": "4f1c…a2e9"
  },
  "signature": "9f3c…20b1",
  "signer_key": "4f1c…a2e9"
}

The batch follows from the arithmetic. A manifest prices one billing unit at a time, and a MonetaryAmount has no representation for a tenth of a cent, so a tool that charges per row advertises a batch it can price in whole cents. A MeteredBillingQuote carries a quotedCost for the whole estimate, so the quote can name the finer unit and count a thousand of them. A quote for 1,000 rows comes to USD 1.00, the advertised price of one batch.

The buyer's kernel runs verify_manifest against your registered key, then carries the sql entry and its ToolPricing forward as the catalog input for a metered quote request. The fixed-price service purchase works differently: its MCP tool returns the quote as application data.

Read more in Pricing Models, which binds quoted units and cost into a governed intent.

Next: publish the registered server as a listing