Machine readable

The same facts this documentation states, in forms a program can read. If you are generating client configuration or checking what exists, start here rather than scraping the page.

The catalogue as JSON

Every source, its tools, its category and its endpoint, as one document:

GET https://port.harborgovcon.com/api/catalog

Each entry carries slug, title, summary, category, tools, tool_count, requires_upstream_key and a fully qualified endpoint. The catalogue on this site is rendered from this payload, so the two cannot disagree about which sources or tools exist.

There is also the published plan ladder as data, which is the same object the gateway enforces rather than a copy of the marketing page:

GET https://port.harborgovcon.com/api/ladder

The server card

A static card for directories and registries that expect one:

GET https://port.harborgovcon.com/.well-known/mcp/server-card.json

The card reports the running build version, so a directory reading it can tell which image it is describing.

A client that needs to discover authentication without sending a request can read the authorization server metadata directly. That is the same document the 401 response points at:

GET https://port.harborgovcon.com/.well-known/oauth-authorization-server
GET https://port.harborgovcon.com/.well-known/oauth-protected-resource/mcp

Status and health

The health endpoint is liveness plus counts. It is deliberately not a status page and deliberately carries no customer data:

GET https://port.harborgovcon.com/healthz

It reports status, the number of servers and the number of tools. Nothing else is added to it, because a health check that leaks account state is a health check that ends up in a monitoring dashboard it should not be in.

For a human-readable answer about whether a source is currently misbehaving, use the status link in the footer rather than polling the JSON.