klaridian()
How-to guidesPlugins

OpenTelemetry

Trace every tool call without writing instrumentation code.

Enable it

npx klaridian generate --spec ./api.yaml --out ./my-server --plugin otel

Every 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.js

This works with Datadog, Grafana Tempo, Honeycomb, or any backend that accepts standard OTLP.

On this page