Spanly shows what happens when an MCP monitoring tool is also a climate risk platform

The Product Hunt listing for “Spanly” promises to show “what AI agents do inside your MCP server.” Click through to the linked domain, spanly.io, and you land on a risk intelligence platform that stress-tests buildings against flood, wind, and seismic force using physics-based simulations.

These are not the same product.

The Product Hunt page is a placeholder or a redirect. The actual business behind spanly.io is an Austrian climate risk analytics company that sells to insurers, governments, and construction firms. It claims 10-centimeter pixel resolution, 100x faster analysis than manual methods, and a 250% operational efficiency gain for underwriting teams. It has nothing to do with the Model Context Protocol, agent observability, or any AI runtime.

The confusion is not malicious. It is instructive.

The MCP observability gap is real, and it is growing.

The Model Context Protocol, introduced by Anthropic in late 2024, standardizes how AI agents connect to external tools and data sources. Adoption has been rapid. By mid-2025, dozens of MCP servers existed for databases, file systems, web browsers, and APIs. Developers building agentic workflows need visibility into what their agents are doing inside those servers — which tools they call, in what order, how long each call takes, whether they retry, and where they fail.

That is what the Product Hunt listing promises: “See what AI agents do inside your MCP server.” It is a pitch for agent observability, a category that currently has few dedicated tools. Developers today rely on logging frameworks like LangSmith, manual console traces, or custom instrumentation. None of these are purpose-built for the MCP protocol’s architecture, where an agent may open multiple parallel connections to different servers, each with its own authentication, rate limits, and error modes.

The fact that a Product Hunt listing can attract attention for a product that does not exist yet tells you something about demand. Developers want this tool. They are searching for it. They are upvoting phantom listings.

The real Spanly is a serious business, just not an AI one.

Spanly.io is a climate risk intelligence platform backed by what it describes as “industry leaders.” It ingests satellite imagery, public registries, and hazard models to produce building-level risk scores for flood, wind, earthquake, landslide, wildfire, and avalanche. Its value proposition is that traditional risk assessments rely on static maps and aggregated data that miss building-specific vulnerabilities. Spanly claims traditional methods miss 70% of vulnerabilities at the property level.

The platform targets a fragmented market. Insurers and reinsurers need property-level underwriting data. Municipalities need climate adaptation planning. Real estate investors need portfolio risk exposure. Spanly’s pitch is that it replaces weeks of manual evaluation with automated analysis at 10-centimeter resolution.

This is a real product solving a real problem. Climate risk is under-modeled, and the insurance industry is struggling to price it accurately. Spanly’s approach — physics-based simulation combined with AI feature extraction from satellite imagery — is technically sound and commercially relevant.

But it is not an MCP observability tool.

What this means for the AI agent tooling market.

The Spanly mix-up is a signal that the MCP observability category is under-served. No major vendor has shipped a dedicated agent monitoring dashboard for MCP servers. The existing observability platforms — Datadog, New Relic, Grafana — are general-purpose. They can ingest MCP logs if you pipe them in, but they do not understand the protocol’s semantics: tool definitions, parameter schemas, server-to-agent handshakes, or the distinction between a tool returning an error and a tool returning an empty result.

A purpose-built MCP observability tool would need to:

• Parse MCP session initialization and tool discovery
• Track individual tool call lifecycles across multiple servers
• Surface latency and error rates per tool and per server
• Visualize agent decision paths — which tool was called, what it returned, and what the agent did next
• Support replay of agent sessions for debugging

None of these capabilities exist in a single product today. Developers are stitching together solutions from LangChain callbacks, OpenTelemetry exporters, and custom logging middleware. It works, but it is fragile and non-standardized.

The takeaway for builders.

The Spanly Product Hunt listing is a placeholder, but the demand it reveals is real. Someone should build the product it describes. The MCP ecosystem is growing fast enough that a dedicated observability layer will become a necessity, not a nice-to-have. Anthropic, OpenAI, and Google are all investing in agent protocols. As agents move from demos to production, the tooling gap will widen.

The real Spanly, meanwhile, will continue selling climate risk intelligence to insurers and governments. It is a good business. It is just not the business the Product Hunt crowd thought it was.

The confusion will resolve when someone ships the actual product. Until then, every upvote on that listing is a vote for a tool that does not exist yet.