generated: '2026-08-09'
method: derived
source: >-
  mcp/catalog-guard-api-mcp.yml (candidate tools) bound to
  openapi/catalog-guard-api-catalog-check-openapi.json (live operations)
surfaces:
  openapi:
    file: openapi/catalog-guard-api-catalog-check-openapi.json
    url: https://catalogguard.noahcortezj-c.workers.dev/openapi.json
    gated: false
    operations: 2
    note: >-
      The spec declares NO operationId on either operation, so bindings below are expressed as
      method + path — the only stable identifiers the provider actually publishes. Nothing was
      invented to fill the gap.
  graphql:
    endpoint: null
    note: /graphql returns 404; no GraphQL surface.
  mcp:
    url: null
    gated: false
    note: >-
      No MCP server exists. tools/list could not be called because there is nothing to call.
      The crosswalk therefore binds CANDIDATE tools, and every confidence below reflects that
      the tool side is projected rather than observed.
crosswalk:
- tool: check_catalog
  category: validation
  rest: ['POST /api/v1/catalog/check']
  binding: rest
  confidence: high
  note: >-
    One-to-one. The tool is the operation; its real input contract is the operation's oneOf
    requestBody schema (csv string or rows array), inherited verbatim.
- tool: get_catalog_guard_health
  category: operations
  rest: ['GET /api/v1/catalog/health']
  binding: rest
  confidence: high
  note: One-to-one, no parameters.
mcp_only: []
rest_only: []
coverage:
  tools_named: 2
  tools_bound: 2
  mcp_only: 0
  rest_operations_total: 2
  rest_operations_with_tool: 2
  note: >-
    Complete overlap, which is expected for a two-operation API. The interesting divergence here
    is not between surfaces but between the API and the product: the marketing site's free
    preflight runs entirely in the browser and never calls this API, so the most-used Catalog
    Guard capability has no API representation at all.