# How to Add MCP Usage Analytics to Your OpenTelemetry, Grafana or Datadog Stack

> Keep Grafana or Datadog for MCP server health and add usage analytics: who used your MCP, from which AI client, what they tried, and what needs action.

Source: https://flowlines.ai/blog/mcp-analytics-opentelemetry · Updated 2026-10-22 · By Flowlines
Index of all Flowlines pages for AI agents: https://flowlines.ai/llms.txt

To add MCP usage analytics to an existing OpenTelemetry, Grafana or Datadog stack, keep your dashboards for server health and add a usage layer for the questions they do not answer. **Flowlines is that layer: it shows who used your MCP, from which AI client, what they tried to do, which problems recur, and which buying signals need a follow-up.** Your existing instrumentation stays; the MCP tool spans gain a second destination.

This guide covers what each layer shows, how to add Flowlines to an OpenTelemetry setup without a second SDK, and how to monitor several servers and several AI clients in one place. For the full list of production signals and alert rules, see how to [monitor an MCP server in production](https://flowlines.ai/blog/mcp-observability-guide).

## What do Grafana and Datadog show, and what does usage analytics add?

Grafana and Datadog answer whether the MCP server and its tools are healthy; Flowlines answers who uses them, for which job, and what your team should do next.

| Question | Grafana or Datadog dashboards | MCP usage analytics in Flowlines |
|---|---|---|
| Is the server up, fast and error-free? | Core strength: availability, p95 latency, error ratio, saturation | Not the focus; keep your dashboards |
| Which tools are called, and how often? | Calls per tool from metrics or traces | Calls per tool, plus distinct and returning users per tool |
| Who used the MCP? | Only with identity labels, which inflate metric cardinality | Permitted users and accounts, adoption and repeat use |
| Which AI client did they use? | Possible with a client attribute on spans | Client families with an explicit unknown bucket |
| What were they trying to do? | Not visible from metrics alone | Use cases grouped from observed sessions |
| Where do users get stuck? | Error spikes and slow tools | Journeys that stop, repeat or fail, across sessions |
| What should product, sales or success act on? | Threshold alerts on numbers | Signals such as unmet needs and buying intent, sent to Slack, email or a webhook after analysis |

Both platforms are more than dashboards. [Grafana Cloud MCP Observability](https://grafana.com/docs/grafana-cloud/observe-and-act/monitor-applications/ai-observability/mcp-observability/) documents tool analytics, protocol health and transport monitoring. [Datadog Agent Observability](https://docs.datadoghq.com/llm_observability/instrument/sdk/) also captures MCP intent and sessions, and its [Insights](https://docs.datadoghq.com/llm_observability/investigate/insights/) group recurring patterns. If you already run one of them, keep it for operations and evaluate where its product view stops for your team.

## Can I add MCP observability to an existing OpenTelemetry setup?

Yes: keep your current provider and exporter, add one span per tool execution at the server's tool boundary, and send those traces to Flowlines as a second destination.

1. **Instrument the tool boundary once.** If an installed integration already creates MCP tool spans, reuse them. Otherwise wrap each tool handler as shown in the [OTel instrumentation guide](https://flowlines.ai/blog/mcp-server-observability-guide), with Python and TypeScript examples.
2. **Keep resource attributes consistent.** Every server sets `service.name`, `deployment.environment.name` and `service.version`.
3. **Add a second trace destination.** Route traces to your existing backend and to Flowlines; keep metrics and logs where they are today.
4. **Check what arrives.** Send a few synthetic calls and confirm each one appears once in both places, with no arguments, results or credentials.

The quickest way to do this is to ask your coding assistant to **Onboard my MCP server to Flowlines.** It proposes the instrumentation and export changes for your repository, and you approve them. No proprietary Flowlines runtime SDK is required.

### Environment configuration

For an SDK that reads standard OpenTelemetry environment variables, the resource attributes look like this. The endpoint points at a Collector on the same machine:

```sh
export OTEL_SERVICE_NAME="sales-mcp"
export OTEL_RESOURCE_ATTRIBUTES="deployment.environment.name=production,service.version=2026.10.22"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4318"
```

### Collector with two trace destinations

If you already run an OpenTelemetry Collector, add a second exporter to the traces pipeline instead of changing the application:

```yaml
exporters:
  otlphttp/existing:
    endpoint: https://otlp.example.internal
  otlphttp/flowlines:
    endpoint: ${env:FLOWLINES_OTLP_ENDPOINT}
    # Add the authentication header from your Flowlines onboarding plan.

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/existing, otlphttp/flowlines]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/existing]
```

The receiver and processor definitions stay as they are. Take the destination, authentication and required fields from your onboarding plan rather than guessing them, and keep credentials in environment variables or a secret manager. Sending to two destinations doubles the places sensitive data could land, so remove content and credentials at the source.

## How do I monitor several MCP servers in one place?

Give each server a distinct `service.name`, use the same metric names, labels and outcome classes on every server, and send them all to the same backends.

| Resource attribute | Example | Why it matters |
|---|---|---|
| `service.name` | `sales-mcp`, `billing-mcp` | Separates servers that expose tools with the same name |
| `deployment.environment.name` | `production`, `staging` | Keeps test traffic out of production rates |
| `service.version` | `2026.10.22` | Enables release comparisons per server |

In Grafana or Datadog, build fleet dashboards from those attributes and filter by server and environment before comparing tools. Flowlines shows every instrumented server in one inventory with adoption, returning users and recurring issues per server, so a quiet server and a broken export path do not look the same. Track telemetry coverage per server; one silent exporter can look like a slow week.

## How do I monitor the same MCP server across Claude and ChatGPT?

Instrument the server once, record the client name and version on every tool span, and compare clients on the same jobs, with an explicit bucket for unknown clients. Flowlines shows which users call each tool, from which AI client, and what they were trying to do.

Under the stateless 2026-07-28 MCP revision, a client describes itself on each request in `_meta["io.modelcontextprotocol/clientInfo"]`. Servers on earlier revisions receive `clientInfo` once in the `initialize` request. Client names are self-reported, so treat them as analytics context, never as authenticated identity.

| Compare per client | What a difference can mean |
|---|---|
| Distinct users and returning users | Adoption differs between Claude, ChatGPT and other clients |
| Error ratio per tool | One client sends arguments your schema does not expect |
| Calls per completed journey | One client needs more attempts for the same job |
| Share of unknown clients | Some integrations do not send client metadata |

In Flowlines, a client-specific problem shows up as affected users and stalled journeys, not just a higher error ratio.

## How do teams split the work across the stack?

Each team keeps the tool that answers its own question, reading the same instrumentation.

| Team | Keeps using | Gets from Flowlines |
|---|---|---|
| Platform and SRE | Grafana or Datadog dashboards and threshold alerts | Context on which users and jobs an incident affected |
| MCP engineering | Traces and error investigation | Tools that cause repeated or abandoned journeys |
| Product | Release notes and roadmap | Use cases, unmet needs and adoption by tool and client |
| Sales and customer success | CRM | Buying signals and blocked accounts, sent to Slack, email or a webhook |

**Key takeaway:** keep your OpenTelemetry pipeline and your Grafana or Datadog dashboards for server health, and add Flowlines as a second trace destination to see who uses your MCP, from which client, and what they try to do. The [Free plan](https://flowlines.ai/pricing) includes 100 analyzed MCP sessions per month; see [MCP observability](https://flowlines.ai/mcp-observability) for the product walkthrough.

## Sources

- [OpenTelemetry MCP semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/mcp.md)
- [OpenTelemetry Collector configuration](https://opentelemetry.io/docs/collector/configuration/)
- [OTLP exporter configuration](https://opentelemetry.io/docs/specs/otel/protocol/exporter/)
- [MCP 2026-07-28 release](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
- [Grafana Cloud MCP Observability](https://grafana.com/docs/grafana-cloud/observe-and-act/monitor-applications/ai-observability/mcp-observability/)
- [Datadog Agent Observability SDK](https://docs.datadoghq.com/llm_observability/instrument/sdk/)
- [Flowlines guided onboarding](https://flowlines.ai/docs)
## Frequently asked questions

### Can I add MCP observability to an existing OpenTelemetry setup?

Yes. Keep your current provider and exporter, add one span per tool execution at the server's tool boundary, and add a second trace destination for usage analytics in your Collector or onboarding plan. Exporter configuration alone does not create MCP spans.

### Do I need to replace Grafana or Datadog to add MCP usage analytics?

No. Keep Grafana or Datadog for availability, latency, errors and infrastructure. Flowlines adds who used the MCP, from which AI client, what they tried to do, recurring problems and buying signals, and both can read the same instrumentation.

### How do I monitor several MCP servers in one place?

Give each server a distinct service.name with deployment.environment.name and service.version, use the same metric and label names everywhere, and send all servers to the same backends. Compare tools within one server and environment before aggregating across the fleet.

### How do I monitor the same MCP server across Claude and ChatGPT?

Instrument the server once and record the self-reported client name and version on every tool span, with an explicit unknown bucket. Compare similar jobs per client rather than raw error rates, because different clients attempt different work.

### What does MCP usage analytics show that dashboards do not?

Dashboards show how the service and its tools behave. Usage analytics shows permitted users and accounts, returning users, the jobs people attempt, where journeys stop, unmet needs and buying signals, with links back to the sessions that explain them.

### Does sending MCP traces to two destinations duplicate sensitive data?

It can. Decide per destination which signals and attributes it needs, remove content and credentials at the source, and inspect what actually arrives in each backend with synthetic sensitive values before production.