T

Stéphane Tailland 32d6014b42 refactor(mcp): generate the tool definitions from the spec

The tools: array was hand-maintained and had drifted from openapi.yaml in two
ways that only surfaced when an agent hit them: create-product omitted
productcode and could never succeed, and list-products declared no parameters
so it could not paginate — which let a model answer a product count that looked
right and had not come from the tool's output.

It is now produced by k8s-platform/tools/generate-mcp-tools.py: deck file
openapi2mcp does the conversion, and the wrapper re-injects the five things
Kong's generator cannot emit — per-tool ACLs, the MCP behavioural annotations,
the response schemas the plugin uses for structuredOutput, the real upstream
host, and JSON-only request bodies. Each is a documented gap; see
k8s-platform/MCP-TOOL-GENERATION.md.

tools-policy.yaml carries the ACLs and doubles as the allow-list: an operation
becomes a tool only if the policy names it. Kong would otherwise expose every
operation in the spec, DELETE included, and can express no authorization at all
from a bearer-token spec — silently, exit 0, no warning.

Same three tools as before, same ACLs. What changed: pagination is now
callable, create-product's required list matches the API (quantityinstock
included, which the hand-written repair had missed), each tool declares its
response schema, and the request body is no longer tripled across three
identical content types.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-29 08:43:36 +02:00

dev

refactor: rename the token-exchange broker to drop the middleware's name

2026-08-29 07:40:03 +02:00

kong

refactor(mcp): generate the tool definitions from the spec

2026-08-29 08:43:36 +02:00

.gitignore

First commit

2026-08-20 13:24:10 +02:00

openapi.yaml

Regenerate the spec against the gateway, not the backend

2026-08-27 06:42:02 +02:00

README.md

MCP server

2026-08-20 17:27:09 +02:00

README.md

catalog-api

Kong routing/policy layer for the catalog slice of classic-models-api (see /Users/stephanetailland/git/classic-models-api), split out per the DDD decomposition in ../kong-konnect-deployment-strategy.md. The backend itself stays a single monolith — only Kong does the domain split.

Two exposure surfaces of the same API, both proxying to the real classic-models-api backend:

REST (kong/rest/) — 14 routes covering products/productlines.
MCP (kong/mcp/) — the same catalog exposed as MCP tools (list-products, get-product, create-product so far; extending to the rest is mechanical), via ai-mcp-proxy.

Auth

openid-connect on both surfaces, with a distinct audience each (catalog-api for REST, mcp-catalog for MCP) and a real RFC 8693 token exchange chain: MCP → catalog-api → classic-models-api (REST's own exchange target), narrowing the token before it ever reaches the backend — the backend never sees a token minted for a different audience. consumer_claims/consumer_by map the JWT sub to a Kong Consumer for per-consumer rate limiting; consumer_groups_claim maps realm roles to Kong Consumer Groups for MCP's per-tool ACLs.

Other policies

Per-consumer + API-level rate limiting, response caching (GET/HEAD), audit log (http-log, endpoint still a placeholder — no real log collector in this lab).

Structure

dev/gitrepository.yaml + dev/flux-kustomization.yaml — this repo, self-referential; deploys ./kong into the catalog domain's dev environment (dependsOn the domain's Gateway infra in dataplane-catalog).
dev/externalsecret.yaml — git deploy key (ESO/Vault).
dev/token-exchange-broker-externalsecret.yaml — the shared client secret Kong uses to authenticate its own token-exchange calls to Keycloak.
kong/rest/, kong/mcp/ — see above.
openapi.yaml — extracted from the live backend, filtered to this domain's paths/schemas.