OpenTelemetry
Trace every tool call without writing instrumentation code.
Enable it
npx klaridian generate --spec ./api.yaml --out ./my-server --plugin otelEvery tool call gets wrapped in a trace span automatically. You don't write any tracing code.
How traces are sent
Traces always go through the standard OTLPTraceExporter, and diagnostic logs go to stderr, never stdout. This matters: writing to stdout would corrupt the server's communication with its client.
Joining the caller's trace
When an MCP client sends W3C trace context in the request _meta (the traceparent, tracestate, and baggage keys, per the MCP specification), the generated server continues that trace. Each tool-call span becomes a child of the caller's span instead of a disconnected root, so a single distributed trace spans the client, the generated server, and the upstream API it calls.
You don't configure anything for this. The server registers the W3C trace-context and baggage propagators and extracts the parent context from every request that carries one. A request without trace context still produces a normal root span.
Code mode
With --architecture code-mode, the model's script can call several API operations in one execute_code call. The execute_code span gets one child span per call, named after the HTTP method and path template (for example GET /pet/{petId}), with the operation name, host, port, and response status as attributes, following the OpenTelemetry HTTP client conventions. A call that returns an error status is marked as an error. Arguments and bodies aren't recorded.
Point it at your backend
The generated server reads standard OpenTelemetry environment variables—no klaridian-specific config:
OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.your-backend.example \
OTEL_EXPORTER_OTLP_HEADERS="api-key=..." \
node dist/src/index.jsThis works with Datadog, Grafana Tempo, Honeycomb, or any backend that accepts standard OTLP.