What is this?
A platform that reconstructs entire AI agent sessions behind Model Context Protocol (MCP) tool calls. By wrapping an MCP server with a 3-line SDK (TypeScript, Python, Go), developers gain a dashboard showing:
- Full session reconstruction: the reasoning path, every tool call, and agent decisions
- Usage clustering: which use cases agents bring to your tools, ranked by volume
- Error analytics: which agent failures are most frequent, and why
- Cost attribution: token spend and latency per tool, per use case, per agent type
- Activation metrics: which teams, workflows, and integrations drive value
Competitors today (Langsmith, Arize, Datadog) trace LLM calls and infrastructure. Nobody owns the layer: "what happens inside my tools when agents invoke them?"
Why this matters now
MCP launched at Claude World 2025 and is becoming the integration standard for agentic workflows. As agents proliferate, the gap between "we published an MCP" and "we understand how agents actually use it" is vast and growing.
Today, MCP providers are blind: they see API adoption numbers but have zero visibility into the sessions, reasoning paths, or cost happening inside agents. This creates three product risks:
1. Feature blindness. Agents discover only 20% of your tool's capabilities. The other 80% sit unused because agents never tried them and you never saw the gap.
2. Silent failures. Agents work around errors by never using problematic patterns. You see "no errors" and ship broken code. Customers quietly use your tool wrong.
3. Upsell invisibility. You can't identify which teams will pay for a premium tier because you don't know their usage patterns. Revenue growth stalls at adoption, not expansion.
Observability is how you solve all three. But observability at scale is hard, and it only works if adoption is high enough to justify the infrastructure. That's why this idea is complex and not a landing-page problem.
Why a landing page would fail here
This idea has three layers of risk that require deep product thinking before any go-to-market makes sense. A landing page papering over these risks would fail in customer discovery.
API design risk: The SDK interface sounds simple (3 lines), but the backend architecture is non-trivial. Do you instrument at the MCP server level, the transport layer, or through agent logs? Each path has wildly different accuracy, latency, and cost. You won't know which tradeoff is right until you ship and see real agent patterns. A landing page promises one design; actual usage will reveal it was wrong.
Business model risk: Pricing could be per-tool ($99/mo), per-session ($0.01 per session), per-token ($0.01 per 1M tokens), or freemium. Each path serves different customer segments and cash-flow profiles. A landing page commits to one; the market may demand another. If your pricing doesn't fit customer budgets, the product fails for business reasons, not technical ones.
Competitive moat risk: Langsmith or Arize could launch MCP observability as a feature in weeks, flattening your differentiation. Our advantage (deep session reconstruction, agent-aware cost attribution) only matters if it takes them 3+ months to match. If it's a 2-week feature lift for a big competitor, you're building to be acquired, not to own a category.
What a realistic 12-month roadmap looks like
Months 1-2: Narrow MVP
- SDK for TypeScript only (Wes's world runs TS-first)
- Session reconstruction from MCP logs with 100% accuracy
- Dashboards: call volume, latency by tool, top error types
- Free tier (no pricing, pure adoption validation)
- 2-3 alpha partners from the MCP ecosystem
Months 3-6: Activation and pricing discovery
- Python SDK (researchers and data scientists use Claude heavily)
- Usage-based pricing ($0.01 per session, cost per agent type)
- Webhook API for error/cost alerts and anomaly detection
- Expand to 15-25 beta partners
- Core metric: adoption rate (% of MCPs wrapped / % published)
Months 7-12: Scale and competitive moat
- Go SDK (ProxyBox and infrastructure-heavy customers demand it)
- Agent cost attribution (cost per agent per use case per workflow)
- Analytics API (customers build custom dashboards)
- Integrations: Langsmith, Arize, LangSmith (two-way sync)
- Self-hosted option (enterprises require air-gapped deployments)
- Core metric: NRR (net revenue retention), expansion revenue
Success looks like: 50+ paying customers, $10k MRR, 70%+ activation rate (MCPs wrapped / MCPs published), NRR > 120%.
Who builds this and why
Why Wes? This lives in the MCP/Claude/ProxyBox ecosystem where Wes already has distribution through Sales Connector, ProxyBox customers, and the Claude developer community. Wes understands agent workflows from Teddy bots and dispatch systems. The technical MVP (3-line wrapping) isn't hard, but the product thinking (which queries matter, how agents fail, what cost models work) requires someone who ships in this space daily.
Founding team shape: 1 founder + 1-2 engineers. The founder must have shipped both SDKs (language binding expertise) and observability (knows signal-vs-noise tradeoffs). Solo founder + contractor ships months 1-3; beyond that, you need a co-founder or early hire with observability experience.
Funding narrative: Observability tools at $5M+ ARR exist (Datadog, Honeycomb, New Relic). A narrower observability layer (MCP-only) reaching adoption early will own that niche. VCs see: "observability SaaS with same margins, narrower TAM initially, defensible if you own category early." Funding window: 6-12 months, $250k-$500k seed.
Honest case: what would have to be true for this to fail
1. MCP adoption stalls. If MCP remains niche and Claude's tool_use evolves differently, the TAM collapses. Observability only works at scale; if MCP never reaches 100k active tools, revenue stays near zero.
2. Langsmith ships this in 6 months. Langsmith could add MCP observability as a feature before you ship a standalone product. Price pressure will be severe; differentiation becomes hard.
3. Self-instrumentation is good enough. If MCP maintainers can add their own logging easily, they won't buy external observability. The product only wins if wrapping an SDK is materially simpler than DIY logging.
4. Agents don't iterate the way we predict. If agents using MCPs simply work without failures or cost overruns, observability becomes luxury. Customers won't pay for dashboards with nothing to see.
Five questions to answer before committing
Test these before you fund a build:
- Is MCP adoption accelerating or plateauing? Check GitHub stars, npm downloads, and Anthropic's MCP registry. If MCP is flatlining 12 months in, the market isn't ready. Only commit if MCP is on exponential growth.
- Who are the first 10 paying customers and why? List them by name (real or archetypal). "MCP developers who need cost tracking" is too vague. "ProxyBox customers using MCPs for LLM-powered workflows" is concrete. If you can't name 10, the TAM is smaller than you think.
- What does it take Langsmith to launch MCP observability? A 1-week feature or a 3-month platform rebuild? If it's a week, don't build; you'll be commoditized in months. Only build if your advantage (session reconstruction, agent cost attribution) takes them 3+ months to match.
- What's the real SDK integration friction? Build the MVP with 2-3 real MCP libraries and measure: How long does integration take? Do developers adopt without hand-holding? Does the "3-line" claim hold up or is it really 15 lines? Real friction is your hidden TAM risk.
- Can you reach 20 paying customers in 90 days without a sales team? This business only works if adoption is bottom-up. If closing the first 5 customers takes 6 months and a sales team, you've picked the wrong GTM and will burn runway on sales overhead that crushes early revenue.
Why this is not a landing-page problem
The technical risk is low (SDKs are straightforward). The product risk is high (What queries do agents need? What cost model works?). The market risk is existential (Does MCP adoption keep accelerating?).
Build a landing page and you'll lose the first customer conversation to "wait, how does your pricing work?" or "this doesn't support Go." You'll discover the API design was wrong after 3 months of implementation. You'll realize your ideal customer isn't MCP maintainers; it's Platform teams at AI-native companies who run MCPs internally.
A concept essay acknowledges this upfront. It says: "I have conviction in the trend and the customer problem. Before I bet months and funding capital, I'm going to spend 90 days in customer discovery, measure these specific metrics, and prove the hypothesis is real." That's the right framing for a complexity-7 idea.
Conclusion
If you're drawn to this because you believe agent-driven tool use is structural (not cyclical) and you have existing distribution in that ecosystem (like Wes does through Claude, ProxyBox, and Sales Connector), spend an intense quarter on customer discovery. Talk to 20 MCP developers and agent builders. Their feedback will either validate this entirely or pivot it into something different.
If you're drawn to it because "observability tools are evergreen" and "agents are hot," pass. Category creation requires conviction that the underlying trend is real, defensible, and ready for a business model. Those aren't obvious yet. Due diligence, not landing page, is the next move.