- Describe one service version, not an entire company or product suite.
- Use truthful current declarations. Do not relax privacy, authority, evidence, or availability fields just to pass a profile.
- Remove every credential and secret. Declare that secret access is required when it is, but never include the secret itself.
- Keep canonical Nexus schema identifiers on
agentserviceprocurement.com.
Build the declaration the checker actually needs.
A Nexus service manifest is a versioned statement about one service. It records identity, contracts, protocol bindings, commercial terms, limits, authority, privacy, evidence promises, health, and provenance without granting trust or permission.
Contract basis: nexus_service_manifest schema version 1.0.0.
Before you begin
If you started with MCP
The MCP workbench copies only public metadata that was actually present. It is not a manifest and its values remain unverified. Keep it beside this checklist while you supply the missing declarations.
MCP transport metadata cannot decide pricing, authority, privacy, evidence, health, provenance, or ownership. It also cannot prove that a tool’s input or output schema is the exact service contract you want buyers to evaluate.
See the field-by-field MCP mapping or create a new local workbench.
Minimum checklist
| Group | What to declare |
|---|---|
| Identity | Manifest, service, version, and provider identifiers; canonical service URI; readable name. |
| Capability | At least one stable capability identifier and name. Capability fit is evaluated elsewhere, not by the ten checks. |
| Contracts | At least one input and one output contract, including media type, digest, and inline or HTTPS schema location. |
| Binding | A protocol family and transport linked to the contract identifiers it actually carries. |
| Commerce | Payment mode and pricing policy; price and rails where the selected mode requires them. |
| Limits | Input/output sizes, maximum timeout, concurrency, retry limit, and required execution authority. |
| Privacy | Data classes, retention behavior, and training use. |
| Evidence | Only the evidence forms the service can actually produce. |
| Operations | Health and freshness declarations with their disclosure state and timestamps. |
| Provenance | Source observation identifiers and evidence references supporting how the record was obtained. |
One joint binding
Input, output, and protocol pass together only when one accepted protocol binding carries contracts that satisfy both schema constraints. Separate input-only and output-only bindings do not combine into a pass.
Useful diagnostic
If all three rows block together, inspect the binding’s family, transport, and schema_contract_ids before changing the individual schemas.
Start with a valid fixture
The bundled example is synthetic and is validated by the repository test corpus. Use it to understand the shape, then replace every identifier and declaration with values that accurately describe your service.
Load the worked manifest in the checker.
Guide reviewed against the frozen v1 schema and compatibility implementation on .