I'm Tim, solo founder of Spanly.

Since MCP got traction in early 2025, I've been convinced that within a few years, agents may use your product more than humans do, and if so, they'll mainly do it via MCP.

Today, MCP monitoring often stops at the HTTP layer, and at best instruments the official SDK to gather a few more insights. You still can't observe any deployed MCP, get the overall view, the sessions, or the analytics. Spanly is my attempt to fill that gap!

Live demo: https://app.spanly.com/share/demo

CLI/SDK source (Apache-2.0): https://github.com/spanlyhq/spanly

The key concept: capture every JSON-RPC request and response your MCP server handles. Put the Spanly CLI in front of any MCP server (or use the TypeScript/Python SDK) and get a live, organized view of all that traffic.

- Error rates and p50/p95/p99 latency per tool, resource, prompt, etc...

- Per-client, per-server, per-version views

- Full session traces to replay what an agent did, with payload

- Adoption and client analytics

- Alerts when a deploy spikes errors

- Data stored in the US or in the EU

It blends with your existing Datadog/Sentry/New Relic through a deep-link.

Under the hood this is built on top of ClickHouse, Postgres and Redis, is deployed on Render and payloads are stored in Cloudflare R2. SDKs and CLI are meant to be simple: packets are forwarded for ingestion. The heavy lifting happens in Spanly backend: pairing requests/responses, aggregating for sessions, extracting analytics and storage.

An MCP is available for agents to debug your production MCP servers. As dog-fooding principle obliges, Spanly MCP is monitored by Spanly.

This is my first solo project. Would love your feedback!

Tim

Spanly is observability for MCP servers, the protocol that lets agents like Claude and Cursor call your product's tools. It's a sidecar proxy, so it works with any language and requires zero code changes.

Live demo (no signup): https://app.spanly.com/share/demo

Sidecar source (Apache-2.0): https://github.com/spanlyhq/spanly

Here's the problem. If your product ships an MCP server (the "Stripe added an MCP" pattern), generic APM sees HTTP requests to /mcp and not much else. An agent calls your tool, gets an error, retries twice and gives up; in your APM that's three healthy POSTs.

Sentry and New Relic both recently added MCP monitoring, which helps if you're on their stack: both are in-process SDKs, TypeScript and Python only, mapping MCP onto their existing span model. If your server is in Go or Rust, or you didn't write it, there's nothing to attach an SDK to. And notifications and MCP logging don't fit a span model at all.

Sentry wrote candidly about hitting this with their own MCP server: it grew to 50M requests/month, and the way they learned requests were silently dying (no result, no error) was users reaching out, because everything looked clean on their side. (https://blog.sentry.io/introducing-mcp-server-monitoring/)

How it works: a Go sidecar proxy sits in front of your MCP server and speaks the protocol itself. Any language, any framework, including servers you don't have source for. It wraps stdio servers too, not just HTTP. Telemetry shipping is async and lossy by design: if Spanly's backend is down, your server doesn't feel it, and drops are counted in the proxy's Prometheus metrics.

It captures every message type, not just tool-call spans, with client identification (Claude, Cursor, Copilot, ChatGPT, Windsurf, Cline, Zed, custom agents) and per-request latency and error breakdowns.

The part I haven't seen elsewhere: a product view next to the engineering view. The engineering side is traces, errors, latency percentiles. The product side answers what teams ask the week after shipping an MCP: which clients are connecting, which tools are growing, how adoption is trending, and how much agents actually do per session.

It cooperates with the APM you already have: W3C traceparent passes through untouched, so MCP traces cross-link with your Datadog or Sentry traces. Credential-bearing headers (Authorization, cookies, API keys) are redacted before telemetry ever leaves the sidecar.

Open core: the sidecar and optional TypeScript/Python SDKs are Apache-2.0; the hosted cloud is the paid part, and the backend isn't open source or self-hostable today. US and EU regions, with telemetry staying in-region.

Pricing: free tier with 100k requests/mo, paid from $49. We meter requests (a request and its response count as one); notifications and MCP log messages aren't billed. The free tier degrades to 10% sampling instead of billing you when you go over.

I've been heads-down on this solo for a while and I'm excited to finally show it. Would love feedback, especially from anyone running an MCP server in production: what do you wish you could see that you currently can't?

Comments URL: https://news.ycombinator.com/item?id=48489664

Points: 1

# Comments: 2

TouchPad feels very good but is a little buggy when the computer rest on some surfaces.

The function keys are not a pain to use, and the keyboard feels very good otherwise.

I installed Fedora and Windows 10 on it. Bought with Ubuntu for the price reduction.

Oled screen is marvelous, battery life is okay: 5h when developing using vscode and tons of extensions. It does get quite hot when doing some 3d stuff but that's expected I guess.

Battery life can be improved by choosing the LCD screen.

It has some flaws, but I find them minor and I value much more the possibility to have a windows Linux dual boot.

Everything is asynchronous, flat hierarchy, only seniors hired as freelancers though, so quite autonomous people. Two dev syncs per week, fine if you skip one for whatever reason. One single manager for 10 people. It works quite well.

For me this is remote working done mostly well.

On some rare cases it is a power move, in such cases either you can play the power game or you can't.

Regarding power games, the real fight happen before the meeting, so if you feel unprepared and you know someone in power is going to pressure you: don't go.

I haven't been able to find a good alternative to the old Google News.

I tried subscribing to one or many newspapers, but they all have too many useless articles inbetween valuable news such that filtering noise takes too much time.

So in the end I still read Google News but I'm getting a sens of negativity and frustration that wasn't there in 2016. And it takes more time to have all the necessary news. Since "Time spent on Google News" is probably an important metric for Google, the situation is not going to improve anytime soon.

Then internet slowly became a place where everything is a business opportunity, and blogs were relayed into the second zone. Google also somehow became much less useful when it comes to find good blogs, probably because of aggressive SEO.

Plus they don't actually explain how it works, how the demo was made and what's the limits of their technology. They only show the good side, so people naturally wants to know the not-so-good side as well.