KrakenD Gateway is a high-performance, declarative API gateway whose configuration is a single source of truth and whose runtime exposes a small but operationally rich set of endpoints — health, debug, echo, and extended runtime metrics. The Naftiko capability for KrakenD wraps that operational surface as MCP tools, giving AI agents a structured lens into a running gateway without touching the control plane it does not have.
What the Capability Covers
The gateway-observability capability targets the operator workflow. KrakenD ships health on /__health, an inspection echo on /__echo/, a debug echo on /__debug/{path}, and an extended-metrics endpoint on /__stats/ exposed on a separate port. The capability turns each of those into a typed tool an agent can call to read the gateway’s state, replay a request, or pull router / proxy / backend / Go-runtime metrics on demand.
MCP Tools Available
get-health, get-echo, get-stats, debug-get, debug-post
Capability Specification
naftiko: "1.0.0-alpha1"
info:
label: "KrakenD Gateway Observability"
description: "Observability workflow for platform operators to check KrakenD gateway health, inspect debug request flow, and pull extended runtime metrics from a running gateway instance."
tags:
- KrakenD
- API Gateway
- Observability
- Health
binds:
- namespace: env
keys:
KRAKEND_GATEWAY_URL: KRAKEND_GATEWAY_URL
KRAKEND_METRICS_URL: KRAKEND_METRICS_URL
capability:
consumes:
- import: krakend-service
location: ./shared/krakend-service.yaml
exposes:
- type: mcp
port: 9090
namespace: krakend-observability-mcp
transport: http
description: "MCP server for AI-assisted KrakenD gateway operational checks."
tools:
- name: get-health
description: "Return the KrakenD gateway health status."
hints:
readOnly: true
call: "krakend-service.get-health"
outputParameters:
- type: object
mapping: "$."
- name: get-stats
description: "Return extended runtime metrics from KrakenD."
hints:
readOnly: true
call: "krakend-metrics.get-stats"
outputParameters:
- type: object
mapping: "$."
- name: get-echo
description: "Return request details from the KrakenD echo endpoint."
hints:
readOnly: true
call: "krakend-service.get-echo"
outputParameters:
- type: object
mapping: "$."
- name: debug-get
description: "Issue a GET against the KrakenD debug endpoint at a sub-path."
hints:
readOnly: true
call: "krakend-service.debug-get"
with:
path: "tools.path"
outputParameters:
- type: object
mapping: "$."
- name: debug-post
description: "Issue a POST against the KrakenD debug endpoint at a sub-path."
hints:
readOnly: false
call: "krakend-service.debug-post"
with:
path: "tools.path"
payload: "tools.payload"
outputParameters:
- type: object
mapping: "$."
Running It
docker pull ghcr.io/naftiko/framework:latest
# Set KRAKEND_GATEWAY_URL and KRAKEND_METRICS_URL in your .env file
docker run -p 9090:9090 \
-v ./capabilities/gateway-observability.yaml:/app/capability.yaml \
-v ./capabilities/shared:/app/shared \
--env-file .env \
ghcr.io/naftiko/framework:latest /app/capability.yaml
KrakenD does not expose a runtime admin API the way Kong does — its configuration is built and shipped as a single declarative file, so the things you ask the gateway at runtime are operational, not administrative. That is exactly the surface an SRE-style agent needs: read health, read metrics, replay a request to debug a failing route, confirm the gateway is seeing what you think it is. The KrakenD capability is part of the Naftiko Fleet.
