· Tim Quinteiro

Introducing Spanly: observability built for MCP

Spanly is observability for MCP servers. Two-minute install, MCP-native telemetry, EU and US data residency.

  • launch
  • mcp
  • observability

You shipped an MCP server. Your customers’ agents are calling it. Tools are being invoked, sessions are being opened, errors are happening, and you have almost no idea what’s going on.

That’s the gap Spanly fills.

Spanly is observability for MCP servers. Built for MCP from the first commit, rather than general telemetry adapted to fit it.

It’s live today, and there’s a free tier you can actually use.

The problem

MCP servers are production infrastructure now. They’re behind agents that customers pay for, internal tools your team relies on, and increasingly, public APIs that anyone can wire into Claude or ChatGPT. But the tooling around them is still in the “console.log and pray” era.

When something goes wrong, the questions you want to answer are MCP-shaped:

  • Which tool got called? With what arguments?
  • Which client called it? Claude Desktop, Cursor, or some agent you’ve never heard of?
  • How long did it take? Did the response actually come back?
  • Is this session the same session that errored on us yesterday?
  • Why is one customer seeing 30% error rates when the rest are fine?

You can answer some of these with generic APM, but you’ll spend more time mapping MCP concepts onto span trees than actually debugging. An MCP request/response is one JSON-RPC exchange: one node, not a tree of spans. We learned that the hard way (we initially called the leaf entity a “trace”, which is wrong in OpenTelemetry’s sense, and the mismatch leaks into the whole product if you let it).

So we don’t try to dress MCP up as something it isn’t. Spanly captures the JSON-RPC packets that actually flow between client and server, and gives you the view that matches.

Two minutes to telemetry

We have two ways in, pick whichever fits your stack:

SDK: a few lines in your MCP server, available for TypeScript and Python.

import { SpanlyClient } from "@spanly/sdk";

const spanly = new SpanlyClient({
  apiKey: process.env.SPANLY_API_KEY,
});

spanly.monitor(mcpServer);

CLI: @spanly/spanly, a single binary that wraps or proxies your MCP server. Zero code change, no language constraint. Useful when you can’t (or don’t want to) instrument the server directly: third-party servers, containerised stacks, or anything you don’t own.

export SPANLY_API_KEY="spanly_us_..."

# wrap your MCP server (works with stdio or HTTP)
npx -y @spanly/spanly run -- node ./server.js

# or, if you can't wrap it, run as a standalone proxy
npx -y @spanly/spanly proxy localhost:3000 localhost:3001

Either way, telemetry shows up in your dashboard within seconds.

What you actually get

  • Every request, searchable. Tool name, client, session, arguments, response, latency. Filter, drill in, follow a session end-to-end.
  • Per-tool, per-client, per-session breakdowns. See which tools are hot, which clients are misbehaving, which sessions are blowing your error budget.
  • Alerts that fire on things you care about. Error rate over 10% in the last 5 minutes. P99 latency above a threshold. Email, webhook, more on the way.
  • Public dashboards. Want to show a status page or a live demo? One toggle. (We use this ourselves; our live demo is a public dashboard.)
  • Spanly MCP. Your agent can debug your MCP server through Spanly. We use this every day on our own infrastructure.

EU and US, separately

If you have customers in Europe, you already know the conversation. Spanly runs two independent regions (Oregon and Frankfurt) with separate storage and separate API endpoints. EU data stays in the EU. API keys carry the region (spanly_eu_..., spanly_us_...) so the SDK routes correctly without you configuring anything.

That’s the default architecture, not a compliance afterthought.

Pricing

  • Free: real free tier, enough requests to evaluate and run small projects.
  • Starter ($29/month): for individual builders and small teams.
  • Business ($99/month): for teams running real production traffic, with longer retention and higher limits.

Usage-based overage on paid plans, no surprise invoices. Annual plans get two months free.

Full pricing here.

Why we built it

I’ve been shipping MCP servers in production for the last year, both as part of contracting work and on agent platforms. Every single one of them eventually hit the same wall: something’s off, customers are complaining, and the only debugging surface is logs scattered across containers.

I built Spanly because I wanted it for myself. It turned out other people wanted it too.

We’re early. The roadmap is long and shaped by what paying customers actually need: faster ingest, deeper search, and analysis that surfaces issues in your MCP server before you go looking for them. If you’re running MCP in production and any of this resonates, the fastest way to influence what we build is to be a customer.

Try it

Tim