API & MCP surface

Endpoints

• GET/api/public/v1/catalog

  Domains, solution areas, artifact types and tags that drive the taxonomy.

• GET/api/public/v1/packages

  Search and filter packages. Query params: q, domain, solutionArea, artifactType, tag, license, status, sort, limit, offset.

• GET/api/public/v1/packages/:packageId

  Full package detail including licensing, contents, versions and dependencies.

• GET/api/public/v1/packages/:packageId/manifest

  The machine-readable manifest Nimble consumes at install time.

• GET/api/public/v1/packages/:packageId/download

  Issues a short-lived signed download URL plus the SHA-256 checksum recorded in the manifest. Add ?redirect=true to be sent straight to the file. Link-only packages return 409.

• GET/api/public/v1/packages/:packageId/dependencies

  Resolved dependency tree with version ranges and optional flags.

• GET/api/public/v1/packages/:packageId/compatibility?nimble=1.4.0

  Whether a package version is compatible with a given Nimble release.

Install lifecycle

1. 1

   Discover

   Nimble queries the catalog and package search to find candidates.

2. 2

   Inspect

   The manifest declares contents, artifact types, licensing and provenance.

3. 3

   Validate

   Compatibility and dependency resolution run before anything is written to a twin.

4. 4

   Download

   A signed URL is issued for the package bundle and the SHA-256 checksum from the manifest is compared against the received bytes.

5. 5

   Install

   Nimble applies the package against its own ingestion contract for ontologies, instances, data, notebooks, ML models and physics models.

Manifest shape

{
  "package": { "id", "name", "version", "status", "summary" },
  "publisher": { "name", "type", "verified" },
  "domains": [ ... ],
  "solution_areas": [ ... ],
  "artifacts": [ { "type", "category" } ],
  "dependencies": [ { "package", "version_range", "optional" } ],
  "compatibility": { "nimble_min", "nimble_max" },
  "license": { "id", "name", "url", "redistribution", "attribution_required" },
  "validation": { "security", "validation" },
  "contents": { ... }
}

The manifest describes the package. How Nimble ingests each artifact type is defined by Nimble's own data contract, which the Marketplace does not attempt to specify.

MCP readiness

Each endpoint maps one-to-one onto a planned MCP tool — search_packages, get_package, get_manifest, resolve_dependencies and check_compatibility — so an agent operating Nimble can plan an installation without any bespoke integration work.