Inspiration

One kilogram of beef equals driving 135 kilometers. Most people don't know this — because carbon footprint tools make you fill out forms instead of just talking. CarbonLens was built on a bet: if tracking carbon were as easy as describing your day to a friend, more people would do it. We used AI agents to turn that bet into reality.

What it does

CarbonLens is an AI agent that calculates your carbon footprint from everyday speech — no forms, no calculators, no searching for emission factors.

Tell it what you did. "I drove 20km, ate 1kg of beef, ran the AC for 3 hours." That's it. The agent parses your words, matches 70+ emission factors via MongoDB, calculates your footprint in kg CO₂e, and delivers a full report.

See where you stand. The report shows your category breakdown (visual pie chart), your global and national percentile ranking, your 30-day trend line with anomaly detection, and a tree-offset equivalent.

Get personalized suggestions. The agent generates ranked reduction plans based on your actual habits — ranked by impact, filtered by feasibility, and responsive to your feedback.

Speak or type. 43 activity keywords supported via Web Speech API. Works in Chinese, English, and Japanese.

How we built it

Agent Architecture — 3 Agents in Sequential Relay

We built CarbonLens using Google ADK (Agent Development Kit) and deployed to Vertex AI Agent Engine. The core is a SequentialAgent that orchestrates three specialized sub-agents:

  1. activity_parser — Parses natural language (Chinese, English, Japanese) into structured activities with quantities and units
  2. factor_matcher — Uses MongoDB MCP (find tool) to query 70 emission factors, then calculates per-activity CO₂e and category breakdown
  3. benchmark_advisor — Uses MongoDB MCP (aggregate + insert-many) to run global percentile ranking, generate 30-day trend analysis, produce Top 5 reduction suggestions, and persist results

MongoDB MCP Integration — The Core

The Agent never touches a database connection string. All database operations go through MongoDB MCP Server (mongodb-mcp-server@1.11.0), connected via ADK's MCPToolset with StdioConnectionParams. This gives us:

  • Credential isolation: the mongodb+srv:// URI lives only in the MCP Server process — invisible to the browser, the Next.js frontend, and even the Agent itself
  • Aggregate pipeline: we use MongoDB's $bucket and $group operators to compute global percentile rankings directly inside the database — no data movement to application memory
  • 4 collections: emission_factors (70 entries), global_benchmarks (5 countries), user_entries (per-session), user_profiles (preferences + feedback)

Frontend — Next.js 14 + TypeScript + Tailwind CSS

The frontend is a thin proxy. Next.js API Routes (/api/carbon/calculate, /api/carbon/history, /api/carbon/report) authenticate and forward requests to Agent Engine. They do not connect to MongoDB — keeping the architecture zero-backend. Visualizations use Chart.js (pie charts, line charts) and custom SVG components (CarbonGauge semi-circle percentile indicator). Voice input uses the Web Speech API with 43 custom activity tag detectors.

Deployment

  • Agent: Vertex AI Agent Engine (us-central1, 0-3 auto-scaling instances)
  • Frontend: Google Cloud Run with Docker, fixed egress IP via VPC Connector + Cloud NAT for MongoDB Atlas allowlisting
  • Model: gemini-flash-latest (Gemini 3.5 Flash)
  • CI/CD: GitHub Actions

Challenges we ran into

MCP connection stability. Our first approach used HTTP-based MCP connections, which had intermittent failures under concurrent agent calls. We switched to stdio-based MCP spawning (npx mongodb-mcp-server launched directly by the Agent process), which proved significantly more reliable and reduced tool-call failures to near zero.

Agent latency optimization. The initial three-agent sequential chain took 30-50 seconds end-to-end. We reduced this by setting model temperature to 0 (since calculations need determinism, not creativity), optimizing system instruction length, and pre-warming the Agent Engine with min-instances=1 during development.

Voice recognition accuracy. Web Speech API struggled with domain-specific terms like "CO₂e" and mixed-language input. We built 43 custom activity tag detectors with regex patterns covering common Chinese, English, and Japanese activity descriptions, improving detection accuracy from ~60% to over 85% in testing.

Cloud Run egress for MongoDB Atlas. Cloud Run's dynamic outbound IPs caused Atlas connection rejections. We configured a Serverless VPC Connector, Cloud NAT with a static IP, and added that IP to Atlas's allowlist — a networking puzzle that took a full day to solve but resulted in a production-grade setup.

Accomplishments that we're proud of

Credential-isolated agent design. Our MongoDB connection string exists in exactly one place — the MCP Server process. The browser, the Next.js frontend, and even the AI agent itself never see it. This is what MCP protocol security is designed for, and we believe our implementation is one of the cleanest demonstrations in this hackathon.

3-agent relay with shared MCP toolset. Two of three sub-agents share the same MCP connection, each using different tools (find vs aggregate) for different stages of the pipeline. The SequentialAgent coordinator guarantees deterministic ordering without race conditions.

70 emission factors across 6 categories. Transport, food, energy, consumer goods, waste, and digital services — sourced from IPCC AR7, Japan's Ministry of the Environment, EPA, and FAO. Every factor is traceable to a published reference.

Production deployment. The agent is live on Vertex AI Agent Engine (projects/445408914210). The frontend is deployed on Cloud Run with fixed-egress networking. The full stack runs on Google Cloud with zero local dependencies.

What we learned

MCP + Agent Engine is a powerful but under-documented combination. Connecting MongoDB MCP via stdio spawning inside Agent Engine required reading ADK source code and experimenting with StdioConnectionParams vs StreamableHTTPConnectionParams. The stdio approach won on reliability for production.

Aggregate pipelines beat application-level ranking. We initially planned to pull benchmark data into Python and sort there. Moving the ranking logic into MongoDB $bucket aggregates cut latency by 40% and kept data inside the database — exactly where it belongs for a carbon ranking engine.

Voice input requires domain-specific tuning. General-purpose speech recognition works for conversation but fails on terms like "CO₂e" or mixed-language input. Our 43 custom tag detectors bridged this gap, and we now believe every domain-specific voice AI needs this kind of tuning layer.

Carbon tracking is as much a UX problem as a calculation problem. Users abandon tools that feel like spreadsheets. Our daily card design — grouping multiple records into one visual summary — came from watching test users get overwhelmed by per-item breakdowns. The lesson: AI agents should not just calculate accurately; they should present humanely.

What's next for CarbonLens: AI Carbon Tracker

Multi-user accounts with preference learning. The agent already has a user_profiles collection and feedback-weighting logic in its system instruction. Enabling persistent accounts would turn CarbonLens from a demo into a daily-use product.

Carbon offset marketplace integration. The system instruction includes pricing data for 6 types of verified carbon offsets (Gold Standard, Verra VCS). Adding an MCP-connected offset marketplace would close the loop: track → reduce → offset.

SDG 13 alignment dashboard. CarbonLens could expand to track progress against multiple UN Sustainable Development Goals — responsible consumption (SDG 12), sustainable cities (SDG 11), and affordable clean energy (SDG 7). The MongoDB data model and agent architecture can scale to accommodate this.

Built With

  • chart.js
  • docker
  • gemini-3.5-flash
  • google-adk
  • google-cloud-run
  • mongodb-atlas
  • mongodb-mcp-server
  • next.js-14
  • tailwind-css
  • typescript
  • web-speech-api
Share this project:

Updates