I'm Austin, the Founder of Shinzo Labs, building open source, OTel-Native observability solutions for MCP servers. I’m excited to share our new Python SDK to pair with the TypeScript SDK we released in July.
The Problem
I built several production MCP servers (Gmail, HubSpot, CoinMarketCap integrations) and hit the same operational wall every time. Traditional APM tools don't understand agent-tool interactions, users can't easily correlate multi-turn conversations, and they can't sanitize PII data from agentic interactions in a clear way.
Many MCP developers I talk to eventually encounter these problems.
What This Does
The new Shinzo Python SDK offers drop-in OTel instrumentation for MCP servers, with auto-detection for FastMCP and traditional MCP SDKs. Three lines of config gets you:
- Distributed tracing across agent → server → API flows
- Session correlation for multi-turn conversations
- Built-in PII sanitization
- Exports to any OTel backend (Datadog, Grafana, Prometheus, or self-hosted collectors)
Why OpenTelemetry Matters
Other observability tools in the space use proprietary formats, and even the ones that support OTel do so as a second-class citizen, not a primary concern. Treating OTel as a primary feature means zero vendor lock-in and compatibility with your existing stack. Switch backends as you need without touching the instrumentation.
What's Next
We’re currently hard at work on new context intelligence features: token optimization analysis to identify which tool responses bloat context windows, and relevance scoring to track which outputs agents actually use.
Multi-Language Support
TypeScript has been available since July. Python releases today. Go and C# planned 2026 (looking for contributors!).
austin-born•14m ago
I'm Austin, the Founder of Shinzo Labs, building open source, OTel-Native observability solutions for MCP servers. I’m excited to share our new Python SDK to pair with the TypeScript SDK we released in July.
The Problem
I built several production MCP servers (Gmail, HubSpot, CoinMarketCap integrations) and hit the same operational wall every time. Traditional APM tools don't understand agent-tool interactions, users can't easily correlate multi-turn conversations, and they can't sanitize PII data from agentic interactions in a clear way. Many MCP developers I talk to eventually encounter these problems.
What This Does
The new Shinzo Python SDK offers drop-in OTel instrumentation for MCP servers, with auto-detection for FastMCP and traditional MCP SDKs. Three lines of config gets you: - Distributed tracing across agent → server → API flows - Session correlation for multi-turn conversations - Built-in PII sanitization - Exports to any OTel backend (Datadog, Grafana, Prometheus, or self-hosted collectors)
Why OpenTelemetry Matters
Other observability tools in the space use proprietary formats, and even the ones that support OTel do so as a second-class citizen, not a primary concern. Treating OTel as a primary feature means zero vendor lock-in and compatibility with your existing stack. Switch backends as you need without touching the instrumentation.
What's Next
We’re currently hard at work on new context intelligence features: token optimization analysis to identify which tool responses bloat context windows, and relevance scoring to track which outputs agents actually use.
Multi-Language Support
TypeScript has been available since July. Python releases today. Go and C# planned 2026 (looking for contributors!).
Links
GitHub (Python SDK): https://github.com/shinzo-labs/shinzo-py GitHub (TypeScript SDK): https://github.com/shinzo-labs/shinzo-ts Discord: https://discord.gg/UYUdSdp5N8
All instrumentation packages are MIT licensed, and we appreciate any feedback from developers building MCP servers for production use cases.