Allows emitting OpenTelemetry traces to Jaeger via OTLP/HTTP JSON protocol, enabling visualization and analysis of distributed tracing data in Jaeger's UI.
Provides a k8s-pod mimicry profile that generates realistic Kubernetes pod telemetry including container metrics and k8s.* resource attributes for simulating Kubernetes environments.
Provides an nginx/http-server mimicry profile that generates realistic HTTP server telemetry including server spans with HTTP semantic conventions, access logs, request counters, and latency histograms.
Core integration that emits OpenTelemetry traces, metrics, and logs to OTLP endpoints, supporting all three OTLP wire formats (gRPC, HTTP/protobuf, HTTP/JSON) for comprehensive observability data collection.
Provides a postgres mimicry profile that generates database client spans with db.system=postgresql attributes and connection pool metrics for simulating PostgreSQL database interactions.
Provides a redis mimicry profile that generates database client spans with db.system=redis attributes for simulating Redis cache/database operations.
Enables modeling of payment service interactions through span attributes like peer.service="stripe" in custom trace generation for simulating e-commerce checkout flows.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@otel-mcp simulate 20 nginx requests with a 5% error rate"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that emits OpenTelemetry traces, metrics, and logs to one or more OTLP endpoints at the same time, in any of the three OTLP wire formats:
grpc — OTLP/gRPC (protobuf over HTTP/2)
http/protobuf — OTLP/HTTP binary protobuf
http/json — OTLP/HTTP proto3-JSON (spec-compliant)
It also ships tool-mimicry profiles that produce realistic signal bundles shaped like well-known tools (nginx, postgres, redis, kafka, aws-lambda, kubernetes pod, generic gRPC service), so you can populate a collector or backend with traffic that looks like a real environment.
uv venv
uv pip install -e .Related MCP server: Mock MCP Server
otel-mcp # stdio transport — wire into any MCP clientOr via an MCP client config (e.g. Claude Desktop, Claude Code):
{
"mcpServers": {
"otel": {
"command": "otel-mcp"
}
}
}If OTEL_EXPORTER_OTLP_ENDPOINT is set on launch, an endpoint named default
is registered using the standard OTEL env vars:
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_PROTOCOL (grpc | http/protobuf | http/json)
OTEL_EXPORTER_OTLP_HEADERS (comma-separated k=v pairs)
OTEL_EXPORTER_OTLP_INSECURE (gRPC TLS toggle)
Tool | Purpose |
| Register a named OTLP destination (url, protocol, signals, headers, …). |
| Drop one endpoint by name. |
| Drop every endpoint. |
| Enumerate current endpoints. |
| Endpoints + available mimic profiles. |
Endpoints are selected per call: every signal-emitting tool accepts an
endpoints: [names] arg. Omit it to fan out to every endpoint that accepts
that signal type.
Tool | Shape of input |
|
|
|
|
|
|
Tool | Purpose |
| Show every profile with its parameters. |
| Run one profile and send its bundle once. |
| Run a profile on a loop to simulate sustained traffic. |
Built-in profiles:
Profile | What it looks like |
| Server spans with HTTP semconv, access logs, request counters & latency histograms. |
| DB client spans with |
| DB client spans with |
| Producer/consumer spans with messaging semconv. |
| Server spans with |
| Resource = full |
| Server spans with |
> add_endpoint name="otel-collector" url="http://localhost:4318" protocol="http/protobuf"
> add_endpoint name="jaeger-json" url="http://localhost:4318" protocol="http/json" signals=["traces"]
> mimic_tool profile="nginx" options={"count": 50, "error_rate": 0.1}
> mimic_tool profile="postgres"
> generate_load profile="kafka" iterations=10 interval_seconds=2
> send_trace service_name="checkout" spans=[
{"name": "POST /checkout", "kind": "server", "duration_ms": 42, "attributes": {"http.response.status_code": 200}},
{"name": "charge_card", "kind": "client", "parent_name": "POST /checkout", "duration_ms": 18,
"attributes": {"peer.service": "stripe"}}
]Write a function returning a MimicBundle in src/otel_mcp/mimics.py.
Register it in the PROFILES dict at the bottom of that file.
Call list_mimic_profiles to confirm it picked up the parameters.
Profiles stay declarative: each returns span/metric/log specs that flow through the same generator pipeline, so they inherit correct resource merging, wire format support, and fan-out automatically.
Register an OTLP destination.
Args:
name: Unique identifier used by other tools to target this endpoint.
url: Collector URL. gRPC: host:port or http://host:port.
HTTP: base URL (/v1/traces etc. is appended automatically).
protocol: One of grpc, http/protobuf, http/json.
signals: Subset of traces, metrics, logs. Defaults to all.
headers: Headers added to every request (auth tokens, tenant ids, ...).
insecure: gRPC only — disable TLS.
timeout_seconds: Per-request timeout.
overwrite: If an endpoint with this name already exists, replace it.
Inputs: name (required), url (required), protocol, signals, +4 more. Returns: object
Remove all endpoints.
Inputs: no named parameters. Returns: object
Repeatedly run a mimic profile to simulate sustained traffic.
Blocks for roughly iterations * interval_seconds seconds. For true
background loops use an external scheduler — this tool is synchronous by
design so the caller sees per-iteration results.
Inputs: profile (required), iterations, interval_seconds, endpoints, +1 more. Returns: object
List registered endpoints.
Inputs: no named parameters. Returns: object
List available tool-mimicry profiles.
Inputs: no named parameters. Returns: object
Emit a realistic bundle of signals mimicking a known tool.
Args:
profile: One of nginx, postgres, redis, kafka,
aws-lambda, k8s-pod, grpc. Call list_mimic_profiles
for profile-specific parameters.
endpoints: Fan-out target endpoints. Defaults to all registered.
options: Keyword args passed to the profile (e.g. {"count": 50}).
Inputs: profile (required), endpoints, options. Returns: object
Remove an endpoint by name.
Inputs: name (required). Returns: object
Send one or more log records.
Each record dict accepts: body, severity (trace/debug/info/warn/
error/fatal), severity_text, attributes, timestamp_ns.
Inputs: service_name (required), records (required), resource_attributes, endpoints. Returns: object
Send one or more metric instruments.
Each metric dict accepts: name, kind (counter/up_down_counter/gauge/
histogram), unit, description, points (list of
{value, attributes}). For histograms, value may be a list of samples.
Inputs: service_name (required), metrics (required), resource_attributes, endpoints. Returns: object
Send one or more spans to the targeted endpoints.
Each span dict accepts: name, kind (internal/server/client/producer/
consumer), attributes, duration_ms, status (ok/error/unset),
status_message, events (list of {name, attributes}),
parent_name (to nest spans within the same batch).
If endpoints is omitted, fans out to every endpoint that accepts traces.
Inputs: service_name (required), spans (required), resource_attributes, endpoints. Returns: object
Report configured endpoints and available profiles.
Inputs: no named parameters. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 11 tools
Every tool has a clearly distinct purpose with no ambiguity. Tools like add_endpoint, remove_endpoint, and clear_endpoints handle endpoint management, while send_log, send_metric, and send_trace target specific telemetry signals. Mimic_tool and generate_load are for simulation, and list_endpoints/list_mimic_profiles/status are for querying, all with non-overlapping functions.
All tool names follow a consistent verb_noun pattern using snake_case, such as add_endpoint, list_endpoints, send_log, and mimic_tool. This uniformity makes the set predictable and easy to understand, with no deviations in naming conventions.
With 11 tools, this server is well-scoped for OpenTelemetry management and simulation. It covers endpoint configuration, telemetry emission, mimicry, and status reporting without being overly sparse or bloated, with each tool serving a clear and necessary role.
The tool set provides complete coverage for the OpenTelemetry domain, including CRUD operations for endpoints (add, remove, clear, list), sending all signal types (logs, metrics, traces), simulation capabilities (mimic, generate_load), and querying (status, list profiles). There are no obvious gaps that would hinder agent workflows.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Stateless MCP gateway and OTel span-streaming bridge for hosted MCP servers.
Cloud hosted Okahu MCP server that helps you manage genAI trace data
MCP server for progressive tool usage at any scale (see https://klavis.ai)
