Skip to content
MirrorFirm

What delivery contract should a lab request for exports and MCP access?

A delivery contract can align downloadable files and MCP responses through stable identifiers, schema versions and release manifests, making ingestion repeatable across access methods.

A buyer can ask for a release manifest containing `release_id`, `schema_version`, file names, checksums and references to usage documentation. JSONL can suit episode-oriented ingestion, while Parquet can support table joins and column-based analysis. The pilot should establish which representation fits the lab's pipeline.

For public MCP access, specify the resource or tool response contract: stable record identifiers, pagination behaviour, available filters and the release version associated with each response. A caller should be able to determine whether successive pages belong to the same release.

Define how omitted fields differ from explicit null values, how timestamps are encoded and how schema changes are communicated. These details prevent ingestion code from quietly reinterpreting missing evidence or combining incompatible records.

MirrorFirm could scope matching exports and MCP representations of generated material. The buyer can test that a request retrieved through either channel resolves to the same linked records within a named release. Public access and technical reproducibility do not establish licence permissions; the delivery documentation should point users to the applicable usage information.

Request a versioned delivery specification that lets the lab reproduce ingestion and identify exactly which generated release it used.

Audience:
Model labs
Content type:
Integration
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Service routing