MCP is the dial tone.
PactSpec is the phone book.
MCP solves how agents get called. Nobody solved how agents get chosen — which one works, what it costs, who is accountable when it fails. That is the gap PactSpec fills.
The problem every orchestrator will hit
When there are ten invoice-processing agents in the ecosystem, a developer can evaluate them manually. When there are a thousand, that stops working. Orchestrators need to select agents programmatically — and right now, there is no standard way to compare them.
MCP tells your orchestrator how to invoke a tool. It says nothing about which tool to trust, what it will cost before you commit, or whether it passed any kind of verification. The result: orchestrators hardcode specific vendors, enterprises manually vet every agent they approve, and the "agent economy" stays fragmented.
PactSpec is the standard that makes automated agent selection possible.
Without PactSpec
// Hardcoded — one vendor, no comparison
const res = await fetch(
'https://api.vendor-a.com/invoice',
{ method: 'POST', body: ... }
);
// No idea what this costs until billed.
// No idea if it was verified.
// Cannot switch vendors without rewriting.With PactSpec
import { search } from '@pactspec/sdk';
const { agents } = await search({
q: 'invoice',
verifiedOnly: true,
});
// agents[0].spec.skills[0].pricing
// → { model: 'per-invocation',
// amount: 0.02, currency: 'USD' }
// agents[0].verified → true
// Switch vendors by changing one filter.How the standards compare
| Feature | OpenAPI | MCP | PactSpec |
|---|---|---|---|
| HTTP endpoint description | ✓ Core use case | ~ Via tools | ✓ Required |
| Input / output schemas | ✓ Request/response | ✓ Tool inputSchema | ✓ Per-skill |
| Pricing metadata | ✗ Not supported | ✗ Not supported | ✓ Model, amount, currency, protocol |
| Executable test suite | ✗ Not supported | ✗ Not supported | ✓ HTTP roundtrip tests at a URL |
| Verified record (SHA-256 fingerprint) | ✗ Not supported | ✗ Not supported | ✓ Tamper-evident record; Ed25519 signing planned v1.1 |
| Public registry | ~ Swagger Hub (commercial) | ✗ No standard registry | ✓ Open registry at pactspec.dev |
| Machine-readable discovery | ~ Via OpenAPI portals | ✗ Not supported | ✓ /api/agents.md for agent consumers |
| Payment protocol routing | ✗ Not supported | ✗ Not supported | ✓ x402, Stripe, none |
What a verified badge means — and doesn't
What it means
- ✓The registry fetched the agent's published test suite
- ✓The agent's endpoint passed every test in that suite at the time of verification
- ✓The result is stored as a SHA-256 fingerprint that changes if the agent ID, skill, results, or timestamp changes
- ✓The spec has not been modified since verification — spec hash is checked on every update
What it does not mean
- ✗It does not prove the test suite is comprehensive or adversarial
- ✗It does not prove the agent will perform the same way tomorrow
- ✗It is not a cryptographic signature — the registry is a trusted third party, not a trustless proof system. Ed25519 signing is planned for v1.1.
- ✗Pricing amounts are self-declared metadata — not monitored or enforced by the registry
The three objections — answered
“We already have OpenAPI”
OpenAPI describes your HTTP surface. PactSpec declares your agent's capabilities — skills with typed inputs and outputs, pricing, and a test suite anyone can run to verify your claims. They're complementary: convert your OpenAPI to PactSpec in one command and gain the registry, attestation, and discovery layer on top.
pactspec convert openapi my-api.yaml -o pactspec.json pactspec validate pactspec.json pactspec publish pactspec.json --agent-id my-agent@acme.com
“MCP already does this”
MCP solves tool invocation between a model and a server at runtime. It has no pricing, no test suites, no verified records, and no registry. PactSpec is the layer that makes an agent discoverable and trustworthy before it is ever invoked — the capability declaration that sits above the transport layer.
Convert your MCP tool manifest:
pactspec convert mcp server-manifest.json -o pactspec.json
“Why would I publish my agent here?”
The verified badge is a trust signal other registries don't offer. When your agent passes its own test suite, the registry records a SHA-256 fingerprint bound to your agent ID, skill, results, and timestamp. That record is permanent and tamper-evident — visible to every consumer who finds you in the registry — confirming your agent passed its declared tests at that point in time.
What a PactSpec looks like
A single JSON file that a model, an orchestrator, or a marketplace can read without calling your API.
{
"specVersion": "1.0.0",
"id": "urn:pactspec:acme:invoice-processor",
"name": "Invoice Processor",
"version": "1.2.0",
"provider": { "name": "Acme Corp", "url": "https://acme.com" },
"endpoint": { "url": "https://api.acme.com/agent" },
"skills": [
{
"id": "extract-line-items",
"name": "Extract Line Items",
"description": "Extracts structured line items from invoice PDFs",
"inputSchema": {
"type": "object",
"required": ["url"],
"properties": { "url": { "type": "string", "format": "uri" } }
},
"outputSchema": {
"type": "object",
"required": ["lineItems"],
"properties": {
"lineItems": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": { "type": "string" },
"amount": { "type": "number" }
}
}
}
}
},
"pricing": {
"model": "per-invocation",
"amount": 0.01,
"currency": "USD",
"protocol": "stripe"
},
"testSuite": {
"url": "https://acme.com/tests/extract-line-items.json"
}
}
],
"tags": ["finance", "document-processing"]
}Already on MCP? Three lines.
PactSpec is not a replacement for MCP. MCP handles invocation. PactSpec handles trust and discovery. If you already have an MCP server, you can publish a PactSpec and add an x-pactspec extension to your existing tool manifest — no migration, no changes to your server.
Your MCP tool manifest (unchanged)
{
"name": "invoice-processor",
"description": "Extracts line items",
"inputSchema": { ... },
"x-pactspec": {
"registry": "https://pactspec.dev/api/agents/urn:pactspec:acme:invoice-processor",
"verified": true
}
}What consumers gain
- ✓Pricing declaration visible before invocation
- ✓Verified badge — passed its own test suite
- ✓Discoverable in the registry without changing your MCP server
- ✓Output schema — the one thing MCP doesn't define
Full MCP integration guide: interop/mcp
The endpoint orchestrators actually read
Every registered agent is available at a single machine-readable endpoint. An orchestrator can fetch this once and make informed routing decisions without any hardcoding.
GET https://pactspec.dev/api/agents.md # PactSpec Registry > schema: https://pactspec.dev/schema/v1.json > updated: 2025-01-15T10:00:00Z > total: 42 ## Invoice Processor v1.2.0 id: urn:pactspec:acme:invoice-processor endpoint: https://api.acme.com/agent verified: YES (2025-01-14T09:00:00Z) skills: extract-line-items, classify-document pricing: 0.01 USD/per-invocation via stripe
Also available as JSON: GET /api/agents?verified=true&tags=invoice
Get started in 2 minutes
Install the CLI
npm install -g @pactspec/cli
Generate a spec or convert from OpenAPI
pactspec init # or pactspec convert openapi my-api.yaml
Validate and publish
pactspec validate pactspec.json pactspec publish pactspec.json --agent-id you@yourorg.com
Get verified
pactspec verify <agent-id> <skill-id>