Compare

mpl vs MCP

Short version: MCP is a transport protocol for agent-tool communication. MPL is a contract/quality/audit layer that runs on top of MCP (or A2A, or plain HTTP). They are not substitutes.

The MPL README puts the stack diagram explicitly: MPL sits above MCP, between your agent logic and the transport. The MPL proxy speaks MCP on the wire; the contracts and quality measurement happen in the layer above.

Fair side-by-side

	MCP	MPL
Layer in the stack	Transport & capability protocol (client-server)	Protocol layer above the transport
Primary concern	How an agent discovers and invokes tools, resources, prompts	Typed contracts, quality measurement, audit trails for those invocations
Type system	JSON-Schema-described tool inputs/outputs, declared per-tool	Versioned `stype` identifiers backed by JSON Schemas in a shared registry; same envelope used across tools
Quality scoring	Not in scope	QoM profiles: schema fidelity, instruction compliance, groundedness, determinism, ontology adherence, tool outcome
Audit/provenance	Not in scope (clients can log)	BLAKE3 content hash, provenance block, QoM report on every envelope
Deployment shape	Server you run; client library in the agent	Sidecar proxy in front of the MCP server; transparent or strict mode
Cross-namespace policy	Per-tool, declared by the tool server	Glob-pattern policies (e.g. `org.finance.*`) applied at the proxy boundary
Substitutable?	No — MCP is the transport	No — MPL composes over MCP, doesn't replace it

When MCP alone is enough

If you're building a single-agent system, the messages are short-lived, nothing downstream needs forensic auditability, and "the tool either returned a value or raised" is all the validation you need — MCP on its own is fine. Don't add a layer for a problem you don't have.

When you also want MPL

You have multiple agents and want the same contract enforced regardless of which tool server it lands at.
You need a quality score on every call, not just success/failure.
You need to point a regulator at a tamper-evident record of what happened.
You want to roll out schema changes gradually — transparent mode first, strict mode once you've seen the traffic.

How they run together

The deployment is a sidecar. Your agent's MCP client points at the MPL proxy instead of the MCP server directly; the proxy forwards to the real MCP server. From the agent's perspective nothing changes; from the operator's perspective, every call now has a contract, a quality score, and an audit record.

Agent —(MCP)—> MPL Proxy —(MCP)—> Your MCP Server
                     |
                     +——— validates contract
                     +——— scores QoM profile
                     +——— applies policy
                     +——— writes audit record

Sources

MPL README, stack diagram and Phase 1/2/3 scope (github.com/Skelf-Research/mpl).
MPL mpl-config.yaml in the repo, showing the proxy's transport.protocol: http upstream model.
MCP: public spec at modelcontextprotocol.io.

If you spot something inaccurate, open an issue.