Publishing targets

One contract, every surface your consumers live on. Publishing is a checklist, not a project: tick the artifacts you want and Elva generates each one from the same contract source, so your spec, docs, SDKs, and agent tools cannot drift apart — they are all views of one promise.

The canonical spec

Every contract gets a hosted OpenAPI spec file — the machine-readable contract in JSON or YAML, at a stable URL you can hand to any tool or partner:

 
  https://api.elva.io/contracts/partner-api/openapi.json

This file reflects the contract, not the raw codebase: only selected endpoints, only exposed fields, with your descriptions and constraints baked in.

Everything else you can generate

Missing a platform you need? The Publishing step has a “Looking for a different platform?” box — tell Elva where you want the contract to land and submit the request.

The MCP target deserves a closer look

Toggling MCP Server turns the contract into a hosted, agent-callable MCP deployment — and this is where the whole contract pipeline pays off. The tools an agent sees are generated from the contract’s endpoints and the contract’s field-level exposure rules, so an AI Agent / MCP contract is your PII-trimmed, description-rich, governance-approved surface — nothing more.

The deployment behaves like any hosted MCP server in Elva: it is served through the enterprise MCP gateway, gets a public install page, and reports into MCP insights & logs.

Where to go next

The enterprise MCP gateway

Where a contract's MCP server runs: auth relay, encrypted credentials, and full call logging.

Sync, drift & the changelog

What happens to published artifacts when the source code underneath them moves.