mpl

Features

Contracts, quality, and proofs for agent traffic

mpl does four jobs at every hop: validate a contract, score quality, apply policy, and write a tamper-evident record. Here is what that looks like in practice.

ContractsRegistryQualityProfilesAuditProvenancePoliciesSDKs

Contracts

Versioned semantic types (stypes)

Every payload declares a stype — a versioned semantic-type identifier such as org.calendar.Event.v1 — backed by a Draft 2020-12 JSON Schema. Validation happens at the protocol layer, so a malformed message never reaches your handler.

  • Versioned identifiers: bump v1 → v2 without breaking existing consumers.
  • The same envelope shape (stype, payload, sem_hash, provenance) is used across every tool and agent.
  • Contract mismatches are rejected at the boundary in strict mode, logged in transparent mode.

Registry

A shared schema registry

Pre-built stypes ship under four namespaces: org.* (calendar, communication, finance, healthcare, notification, permission, user, workflow, agent, feedback), data.* (tables, records, queries, file metadata), eval.* (RAG queries, search results, feedback), and ai.* (prompt templates, completions, reasoning traces).

  • Drop your own contract at registry/stypes///v/schema.json.
  • Namespaces let policies target whole domains, e.g. org.finance.*.
  • The registry API service (mpl-registry-api) serves schemas to proxies and SDKs.

Quality

Six quality-of-message metrics

Pass/fail is not quality. mpl scores every message against up to six QoM metrics so behavioural drift shows up before it becomes a customer-visible outage.

  • schema_fidelity — does the payload match the contract structurally?
  • instruction_compliance — were upstream constraints respected?
  • groundedness — are claims backed by sources?
  • determinism — is output stable across runs?
  • ontology_adherence — are domain rules respected?
  • tool_outcome — did side effects match the declared intent?

Profiles

Composable QoM profiles

Profiles are JSON files that compose the metrics you care about. Two ship in the registry: qom-basic (schema fidelity only) and qom-strict-argcheck (production-grade). Author your own under registry/profiles/.

  • Require a profile per stype glob — strict where it matters, light where it does not.
  • Thresholds are enforced at the proxy boundary.
  • Profiles are versioned config, so quality policy lives in the same place as your contracts.

Audit

Tamper-evident audit trails

Each envelope carries a BLAKE3 content hash (sem_hash) of the canonicalised payload, a provenance block, and its QoM report, written to an append-only record. That record is what you point a regulator at.

  • BLAKE3 hashing makes records tamper-evident by construction.
  • Sink the audit trail wherever you like — mpl produces the evidence, you own the store.
  • Records map to common regulatory asks (SOX, GDPR, HIPAA, EU AI Act) as primitives, not certifications.

Provenance

Provenance on every hop

The provenance block records who emitted a message (agent_id) and why (intent). Paired with the content hash, a chain of agent calls stays attributable end to end.

  • agent_id + intent travel with the payload, not in a side channel.
  • Provenance is part of the hashed record, so it cannot be silently rewritten.
  • Policies can require specific provenance fields before a message is allowed through.

Policies

Glob-pattern policies at the boundary

One policy language, enforced at the proxy, instead of validation scattered across every receiver. Require a QoM profile, mandatory provenance fields, or namespace allowlists for stypes matching a glob.

  • e.g. org.finance.* requires qom-strict-argcheck; org.healthcare.* requires a consent reference.
  • Policy is enforced regardless of which tool server the message lands at.
  • A new agent cannot quietly skip validation — the proxy is on the path.

SDKs

Python & TypeScript SDKs

pip install mpl-sdk or npm install @mpl/sdk. Both return valid, qom_passed (or qomPassed), and the response payload, so reading the verdict is a single attribute access.

  • The Rust core (mpl-protocol) handles the envelope, hashing, and validation.
  • The proxy (mpl-proxy) and CLI (mplx) run the sidecar.
  • A Helm chart (helm/mpl-proxy) deploys the proxy to Kubernetes.

Frequently asked questions

Is mpl a guardrail or content filter?

No. Guardrails ask “is this safe?” mpl asks “did this meet the contract, and can you prove it?” They are different layers and run alongside each other.

Do my agents have to change?

No. mpl runs as a sidecar proxy. Agents point at the proxy address instead of the tool server; the proxy validates, scores, records, and forwards.

What transports are supported?

MCP for client–server, A2A for peer-to-peer, and plain HTTP. A2A hardening is a Phase 3 item — check the repo release notes before depending on it in production.

Is it really open source?

Yes, MIT licensed. You run the proxy yourself and sink the audit trail wherever you like. There is no hosted service.

Ready to try it?

Follow the two-minute start and put mpl in front of an MCP or A2A server in transparent mode.

Go to Quickstart →