CLI certainly is better than local MCP. But nowadays, most MCPs are remote and the comparison fall short, at the notable exception of `gh` in a coding environment. But having CLI already authenticated is not guaranted either!
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!
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!
It all boils down to the fact that people need to feel useful. This is part of the society as a whole. During this meetings, look at who need attention, and praise their propositions.
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.
If I had to guess why there are no such lightweight library, it is because when somehow the library API doesn't provide what you want, you cannot hack the library itself easily. If you import the source code you may have trouble building it, and maintening such "patch" is not a lot of fun.
That was very true for a long time. But now with cmake and a package manager like hunter, it became quite easy and pleasant to work with dependencies. ExternalProject_Add() may also work.
Handling malloc() failure is almost never done for short lived programs. For instance git used to fail as soon as an error popped of (whether be it malloc() or open(), etc...). It just is much simpler and convenient to do so.
While C has no special error handling mechanism in place, error handling can still be done reasonably. IMO, the big reason for why malloc() errors are rarely handled is because it is quite hard to come with a viable fallback strategy.