Show HN: Spanly - See what AI agents do inside your MCP server(spanly.com)
spanly.com
Show HN: Spanly - See what AI agents do inside your MCP server
https://spanly.com/
2 comments
Hi HN!
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
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
This is great and definitely under-served right now, will take a look. I have done a lot of primary research on MCP observability so know what I am looking for :)
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?