Skip to main content
FastMCP includes native OpenTelemetry instrumentation for observability. Traces are automatically generated for tool, prompt, resource, resource template, and task management operations, providing visibility into server behavior, request handling, and provider delegation chains.

How It Works

FastMCP uses the OpenTelemetry API for instrumentation. This means:
  • On by default - Instrumentation is active out of the box, no opt-in required
  • No overhead when unused - Without an SDK, all operations are no-ops
  • Bring your own SDK - You control collection, export, and sampling
  • Works with any OTEL backend - Jaeger, Zipkin, Datadog, New Relic, etc.
Because FastMCP only depends on the OpenTelemetry API, span creation is a no-op until you configure an SDK and exporter — so being on by default costs nothing until you opt into collection.

Turning Telemetry Off

To disable FastMCP’s instrumentation entirely, set FASTMCP_ENABLE_TELEMETRY=false (or fastmcp.settings.enable_telemetry = False). When disabled, FastMCP creates no spans even if an SDK is configured.

Enabling Telemetry

The easiest way to export traces is using opentelemetry-instrument, which configures the SDK automatically:
Then run your server with tracing enabled:
Or configure via environment variables:
This works with any OTLP-compatible backend (Jaeger, Zipkin, Grafana Tempo, Datadog, etc.) and requires no changes to your FastMCP code.

OpenTelemetry Python Documentation

Learn more about the OpenTelemetry Python SDK, auto-instrumentation, and available exporters.

Tracing

FastMCP creates spans for all MCP operations, providing end-to-end visibility into request handling.

Server Spans

The server creates spans for each operation using MCP semantic conventions: For mounted servers, an additional delegate {name} span shows the delegation to the child server.

Client Spans

The FastMCP client creates spans for outgoing requests with the same naming pattern (tools/call {name}, resources/read, prompts/get {name}, and tasks/{operation}).

Span Hierarchy

Spans form a hierarchy showing the request flow. For mounted servers:
For proxy providers connecting to remote servers:

Background tasks

Background task traces have two parts:
  • Task submission and management requests use normal client-to-server context propagation. tasks/get, tasks/update, and tasks/cancel server spans are descendants of the corresponding FastMCP client spans.
  • Deferred execution runs in a Docket worker. Docket records its CONSUMER span as a new trace root with a span link to the submission context, rather than making it a child of the submission span. Custom spans created inside the task are children of that worker span.
Span links preserve the causal relationship without forcing worker sampling to inherit the submit trace’s sampling decision. Some tracing backends do not display links prominently, so the worker trace may look disconnected even though the link is present. Frequent status polling can produce more detail than you need. You can drop those client and server spans with a sampler that checks the span name before delegating to ParentBased:
The name check must happen before ParentBased delegates. If the name-based sampler is nested inside ParentBased, it is not consulted for child spans whose parent was already sampled.

Programmatic Configuration

For more control, configure the SDK in your Python code before importing FastMCP:
The SDK must be configured before importing FastMCP to ensure the tracer provider is set when FastMCP initializes.

Local Development

For quick local trace visualization, otel-desktop-viewer is a lightweight single-binary tool:
Run it alongside your server:
For more features, use Jaeger:
Then view traces at http://localhost:16686

Custom Spans

You can add your own spans using the FastMCP tracer:

Where custom spans help most

Custom spans are most useful around work that is expensive or hard to debug:
  • External calls such as databases, vector stores, HTTP APIs, or queue operations
  • Multi-step tool logic where one stage dominates latency
  • Prompt or resource generation that fans out to other systems
  • Sampling calls made from inside a tool via ctx.sample(...)
Avoid wrapping every small helper function or simple in-memory transformation. That usually adds noise without making traces easier to interpret.
  • Use {tool_name}.{operation} or {resource_name}.{operation} for child spans such as search.fetch, search.rank, or docs.render
  • Add attributes that explain workload shape, such as counts, sizes, cache hits, or IDs
  • Do not record secrets, prompts with sensitive user data, or raw tokens as span attributes
  • Let exceptions propagate unless you have a specific recovery path; FastMCP’s server spans already mark failures and record exceptions

Instrumenting tools, prompts, and resources

Sampling calls inside tools

If your tool uses ctx.sample(...), keep the LLM work nested under the tool span so traces show both application logic and model latency together. For providers with their own OTEL integrations, prefer enabling that instrumentation rather than manually creating a span around every model call. For example, if you use Google GenAI, logfire.instrument_google_genai() will emit child spans with token and request metadata under the active FastMCP tool span.

Exporter choices

  • For local debugging, ConsoleSpanExporter or otel-desktop-viewer gives quick feedback with minimal setup
  • For shared environments, use OTLP exporters to backends like Logfire, Jaeger, Tempo, Datadog, or New Relic
  • If traces are too noisy, tune sampling in your OpenTelemetry SDK instead of removing FastMCP instrumentation

Error Handling

When errors occur, spans are automatically marked with error status and the exception is recorded:

Attributes Reference

Migrating from v3.1 or earlier: The rpc.system, rpc.service, and rpc.method span attributes were removed in favor of the MCP semantic conventions listed below. If you have dashboards or alerts keyed on those rpc.* attributes, update them to use mcp.method.name and the fastmcp.* attributes instead.

MCP Semantic Conventions

FastMCP implements the OpenTelemetry MCP semantic conventions:

Auth Attributes

Standard identity attributes:

FastMCP Custom Attributes

All custom attributes use the fastmcp. prefix for features unique to FastMCP: Provider-specific attributes for delegation context:

Testing with Telemetry

For testing, use the in-memory exporter: