A 5-person Andela AI Engineering Bootcamp capstone squad's CrewAI system that plans a day-by-day, budget-constrained trip. My contribution: the custom MCP tools that ground the agents in real flight, exchange-rate, and destination-cost data.
Hugging Face Spaces go to sleep after a period of inactivity. If the demo above doesn't load right away, give it a minute to wake up and reload. After it restarts, close the build log console to see the full app interface.
Technical Deep Dive
Core serviceThird-party APIData storeClient / UI
For the full detail beyond what fits here, these are standalone interactive diagrams (they open in a new tab, sized for a wide screen):
The squad's CrewAI system runs three agents in sequence: the Flight + Forex Agent and Budget Profiler Agent both call out to a shared MCP tool server for grounded data, then the Planner Agent synthesizes their structured outputs into a day-by-day itinerary and budget table. It does not call any tools itself, only reasons over what the other two agents already produced.
The MCP server is kept as its own module specifically so tool dependencies and runtime stay decoupled from the agent logic, and so the same tools could be reused by another client or deployed independently later.
The UI is a Gradio chat interface with history, a live step tracker, and an MCP trace tab showing raw tool call/result JSON as the crew runs, for example a 7-day Paris trip on a $4,000 budget, broken down day-by-day with a final accommodation/food/transport/entertainment table.
My Contribution: Custom MCP Tools
My part of the squad's build was the three custom MCP tools that give the agents grounded, real data to reason over instead of letting the LLM guess at prices, each backed by a real external source, not mocked data:
`search_flight_tool`: calls SerpApi's Google Flights engine, resolving city names to IATA codes and making a second follow-up call (using the cheapest outbound offer's departure token) to fetch matching return flights, since Google Flights requires two separate requests for round trips
`get_exchange_rate_tool`: pulls live rates from Open Exchange Rates' free tier (USD-based only) and computes any non-USD currency pair via USD triangulation, caching results in memory for an hour to stay within the free-tier request limits
`estimate_destination_costs_tool`: scrapes Numbeo's cost-of-living pages for meal, transit, taxi, and rent data, derives low/average/high daily estimates, and applies a monthly seasonality multiplier, chosen over Numbeo's paid API specifically to avoid cost on a capstone project
Design Decisions & Team Process
This was built as a capstone requirement for the Andela AI Engineering Bootcamp, evaluated against a fixed checklist: a multi-agent system with at least two coordinating agents, at least one MCP server/client exposing two or more custom tools actively used by the agents, built on a named framework (CrewAI), with input/output guardrails and error handling.
Five people split the work: architecture and repo setup, the agent logic itself, my MCP tools, MCP integration into CrewAI, and the Gradio UI were each owned by a different squad member and merged into one working system.
The crew runs agents sequentially rather than hierarchically: an earlier hierarchical setup routed tasks through a manager step that didn't reliably invoke the MCP tools, so the team moved to a direct sequential process where tool use was consistent.
Problems & Challenges
Free-tier API limits shaped the tools' design directly: SerpApi and Open Exchange Rates both cap monthly request volume, so in-memory caching (1 hour for FX, 24 hours for destination costs) was necessary to stay within budget during development and demos
Two CrewAI framework bugs had to be worked around: guardrail retries corrupting task output on validation failure, and a race condition when multiple agents called the MCP stdio server concurrently; both patched at the integration layer rather than waiting on an upstream fix
Numbeo has no official API for this use case, so the destination-cost tool depends on scraping HTML that can change without notice: a documented, accepted fragility of that approach
Limitations & Improvements
The MCP server currently runs locally over stdio as a subprocess of the crew: the team's own notes flag it could be deployed independently as a remote HTTP server if reused by another client
In-memory caches for exchange rates and destination costs reset on every process restart since there's no external cache store: worth adding if the tools saw sustained traffic
The planner is explicitly instructed not to invent missing prices and to flag assumptions when upstream data is partial, an intentional accuracy-over-completeness trade-off rather than a gap, but it does mean thin API responses show up as visible caveats in the output rather than silently smoothed over
Stack
PythonCrewAIModel Context Protocol (MCP)GradioHugging Face Spaces