Inspiration
BluePulse was inspired by a simple problem: during floods and other water-related emergencies, useful information is often scattered across maps, infrastructure datasets, environmental sources, and community reports. This makes it difficult to quickly understand what is happening and decide what action to take.
We wanted to explore how WebMCP could turn an environmental intelligence platform into something an AI agent can actively operate, rather than just a dashboard that humans have to navigate manually.
BluePulse builds on the open-source foundation of FloodGraph and extends it toward agent-operable environmental and disaster-response intelligence.
What it does
BluePulse is a map-based environmental intelligence platform focused on flood and disaster-response scenarios.
It combines real and open geographic data to help users and AI agents understand places, infrastructure, points of interest, route incidents, flood context, and potential response actions.
Through WebMCP, BluePulse currently exposes six operational tools:
analyze_place_flood_contextget_place_poisreport_route_incidentget_route_risk_summaryrecalculate_routeclear_route_incidents
These tools allow an AI agent to discover BluePulse capabilities, understand their input schemas, and execute them directly through the browser.
For example, an agent can retrieve relevant infrastructure for a location, analyze preliminary flood context, report an incident affecting a route, inspect route risk, and request a recalculation that avoids active incidents.
BluePulse is designed as a decision-support prototype and does not claim to provide certified flood simulation or operational emergency-response predictions.
How we built it
BluePulse was developed as a hackathon MVP by extending the existing FloodGraph open-source project instead of rebuilding its mapping and graph-processing foundation from scratch.
The application uses React and TypeScript for the interface, MapLibre for the interactive map, and Pyodide/WebAssembly with NetworkX for graph-related processing in the browser.
We integrated multiple open geographic and environmental data sources, including OpenStreetMap-based information and public POI datasets, while maintaining local fallbacks where necessary to keep the application usable when external providers are unavailable.
The WebMCP integration uses document.modelContext to register application capabilities as tools. Chrome can then discover them through getTools(), inspect their inputSchema, and execute them using executeTool().
During final validation, we tested every exposed WebMCP tool individually. We originally had ten tools, but removed four that were redundant or were never invoked by BLUE. The final implementation exposes only the six tools that participate in real agent workflows.
Challenges we ran into
One of the main challenges was working with external geospatial services from a browser-based application.
During development we encountered unavailable ORS proxy endpoints, CORS restrictions with some Overpass endpoints, inconsistent geocoding results, and differences between local development and the production deployment.
We therefore implemented fallback strategies and separated external-service failures from the WebMCP layer itself.
Another important challenge was deciding what should actually be exposed as a WebMCP tool. Initially, we exposed ten capabilities. After testing them through executeTool(), we found that four were redundant because the application already handled those operations internally through the map, geocoder, or UI actions.
Instead of keeping unused tools for the sake of having a larger toolset, we removed them and kept six operational tools that BLUE genuinely uses.
Accomplishments that we're proud of
We successfully implemented and validated WebMCP in a deployed environmental intelligence application.
Chrome can discover BluePulse tools directly from the page, inspect their schemas, and execute them through document.modelContext.
We are particularly proud that the final toolset was validated based on actual usage rather than only registration. This resulted in a cleaner six-tool interface designed specifically for agent interaction.
We also preserved the strengths of the original FloodGraph architecture while extending it with environmental context, real geographic information, route incidents, response intelligence, and agent-operable capabilities.
Most importantly, BluePulse demonstrates that WebMCP can be used for more than simple web automation: it can expose meaningful domain capabilities that allow agents to interact with environmental and disaster-response systems.
What we learned
We learned that exposing many tools does not automatically make an application more agent-friendly.
Clear descriptions, structured input schemas, predictable outputs, and a small set of meaningful capabilities are more valuable than a large collection of redundant tools.
We also learned that WebMCP creates a useful separation between the human interface and the agent interface. A person can continue interacting with the map normally, while an agent can discover and execute the underlying capabilities directly.
Finally, building around real external data highlighted the importance of graceful degradation, fallback strategies, and transparent limitations when developing decision-support applications.
What's next for BluePulse
The next step is to move BluePulse from a hackathon prototype toward a more robust environmental intelligence platform.
Future work includes integrating additional real-time environmental and hydrological data sources, improving flood-risk and uncertainty models, strengthening route and infrastructure analysis, and expanding beyond floods into additional environmental-risk scenarios.
We also want to expand the WebMCP layer so authorized agents can coordinate more complex workflows across environmental intelligence, infrastructure monitoring, community information, and emergency-response systems.
Our long-term vision is for BluePulse to become environmental intelligence that agents can not only understand, but act on.
Built With
- datos.gov.co
- javascript
- node.js
- openrouteservice
- openstreetmap
- overpass
- serverless
- sispro
- typescript
- vercel
- webmcp
Log in or sign up for Devpost to join the conversation.