AgroAgent

KI-Agent für die chilenische Agrarnische, aufgebaut mit einer Agentenarchitektur über das Model Context Protocol (MCP). Statt eines monolithischen Backends stellen vier unabhängige MCP-Server spezialisierte Tools bereit, die ein Orchestrator über eine Agentenschleife mit dem Anthropic SDK koordiniert.

Architektur

apps/
  web/            Next.js 16 + TypeScript + Tailwind v4 + Recharts
  orchestrator/   FastAPI -- MCP host + agent loop (Anthropic SDK) + rutas REST de dashboard
mcp-servers/
  mcp-weather/    tool: get_weather_forecast (Open-Meteo)
  mcp-prices/     tool: get_commodity_price (datos abiertos ODEPA)
  mcp-db/         tools: get_farmer_history, register_planting (PostgreSQL/SQLAlchemy async)
  mcp-rag/        tool: search_sag_documents (RAG sobre normativa SAG -- Pinecone + Voyage AI)
packages/
  shared-types/   Modelos Pydantic compartidos entre orchestrator y mcp-servers

Der Orchestrator verbindet sich als MCP-Client mit den 4 Servern, fasst deren Tool-Katalog zu einem einzigen zusammen und stellt bereit:

• POST /chat – konversationeller Endpunkt (Claude entscheidet je nach Kontext, welche Tools verwendet werden)

• GET /weather, GET /farmers/{id}/history, GET /prices/trend – deterministische REST-Routen für das Dashboard, die die Tools direkt aufrufen, ohne den LLM zu durchlaufen

Der Wert des Projekts liegt nicht darin, jede Quelle einzeln bereitzustellen, sondern darin, dass der Agent sie miteinander verknüpft: Beispielsweise den Anbauverlauf eines Landwirts mit der Wettervorhersage seiner Region und dem aktuellen Preis seines Produkts in Beziehung zu setzen, um konkrete Entscheidungen vorzuschlagen – und dabei bei Bedarf die genaue SAG-Resolution zu zitieren.

Related MCP server: leafengines-mcp-server

Stack

• Backend: Python 3.12+, FastAPI, mcp SDK (v2), SQLAlchemy async + asyncpg, Pinecone, Voyage AI, Anthropic SDK, uv (Monorepo-Workspace)

• Frontend: Next.js (App Router), TypeScript, Tailwind CSS v4, Recharts, pnpm

• Daten: PostgreSQL (Docker), Open-Meteo API, ODEPA (CKAN-Datastore-API), regulatorische Dokumente des SAG

Voraussetzungen

• Python 3.12+ und uv

• Node 20+ und pnpm

• Docker (für PostgreSQL)

• API-Schlüssel: Anthropic, Pinecone, Voyage AI

Einrichtung

# Backend (Python workspace completo)
uv sync --all-packages

# Frontend
cd apps/web && pnpm install && cd ../..

# Base de datos
docker compose up -d postgres

Erstelle apps/web/.env.local:

NEXT_PUBLIC_ORCHESTRATOR_URL=http://localhost:3001

Projekt starten (6 Prozesse)

# Terminal 1
uv run --package mcp-weather uvicorn mcp_weather.app:app --reload --port 4001

# Terminal 2
uv run --package mcp-prices uvicorn mcp_prices.app:app --reload --port 4002

# Terminal 3 (ajusta el puerto de Postgres si no usas el 5432 por defecto)
DATABASE_URL="postgresql+asyncpg://agroagent:agroagent@localhost:5432/agroagent" \
  uv run --package mcp-db uvicorn mcp_db.app:app --reload --port 4004

# Terminal 4
PINECONE_API_KEY="..." VOYAGE_API_KEY="..." \
  uv run --package mcp-rag uvicorn mcp_rag.app:app --reload --port 4005

# Terminal 5
ANTHROPIC_API_KEY="..." \
  uv run --package orchestrator uvicorn orchestrator.app:app --reload --port 3001

# Terminal 6
cd apps/web && pnpm dev

Frontend unter http://localhost:3000.

Architekturentscheidungen

• MCP-Transport: streamable-HTTP, nicht stdio – jeder MCP-Server ist ein eigenständiger Dienst mit eigenem Port/Container, näher an einer echten Microservice-Bereitstellung.

• Backend in Python/FastAPI statt NestJS/TypeScript: bewusste Entscheidung aufgrund der Marktnachfrage und um polyglotte Vielseitigkeit zu demonstrieren (das Frontend blieb in TS/React).

• RAG: Das Chunking respektiert die nummerierte Struktur der chilenischen Rechtsverordnungen (2.1, 3.1.1 usw.), anstatt nach fester Zeichenanzahl zu schneiden; die Metadaten jedes Chunks enthalten die Verordnungsnummer, damit der Agent die Quelle zitieren kann.

• Vom Agenten getrennte REST-Routen: Das Dashboard leitet deterministische Daten (Wetter, Verlauf, Preise) nicht über den LLM – das vermeidet unnötige Kosten und Latenz; beide Ebenen nutzen dieselben zugrunde liegenden MCP-Tools.

Bekannte Einschränkungen / offene Punkte

• Keine Authentifizierung: farmer_id wird explizit übergeben, es gibt keine Benutzersitzung.

• Es gibt keine Route zum Anlegen neuer Landwirte (POST /farmers) – die Testdatensätze wurden manuell eingefügt.

• mcp-rag unterstützt keine gescannten PDFs ohne Textebene (würde OCR erfordern).

• Es gibt kein separates Dockerfile pro Dienst – docker-compose.yml deckt nur PostgreSQL ab.

• Die Kulturnamen in mcp-db sind nicht gegen die Produktnamen von ODEPA in mcp-prices normalisiert.