Self-hosted service
Azure-Samples/azure-ai-travel-agents avatar
Azure-Samples/azure-ai-travel-agents

azure-ai-travel-agents: Multi-Orchestrator MCP Reference App on Azure Container Apps

A robust enterprise application sample (deployed on ACA) that leverages MCP and multiple AI agents orchestrated by Langchain.js, Llamaindex.TS and Microsoft Agent Framework.

482 stars179 forksTypeScriptMIT

At a glance

What is it?
azure-ai-travel-agents is a modular reference application that demonstrates how to coordinate multiple MCP servers written in four different languages with three AI orchestration options: LangChain.js, LlamaIndex.TS, and Microsoft Agent Framework. It targets enterprise developers who want a working, deployable starting point for multi-agent AI on Azure.
Who is it for?
azure-ai-travel-agents is a good starting point for developers who want to see MCP server implementation in Python, Node.js, Java, and .NET alongside three orchestration libraries in a single deployable project. It is a reference application, not a production travel booking system.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What the Application Demonstrates and Who It Is For

azure-ai-travel-agents is not a travel booking product. It is a reference application for enterprise developers who want to understand how to architect multi-agent AI systems on Azure using the Model Context Protocol (MCP). The application simulates a travel agency scenario with four specialised agents: one that extracts customer preferences from queries, one that recommends destinations, one that generates itineraries, and one that echoes input for testing MCP connectivity.

The project makes the following architectural choices concrete: each agent's tools are implemented as an independent MCP server, not as code inside the orchestrator. The MCP servers are written in Python, Node.js, Java, and .NET, demonstrating that the protocol is language-agnostic. Three separate orchestration services (LangChain.js, LlamaIndex.TS, and Microsoft Agent Framework) are each implemented as standalone API services and can be swapped without modifying the MCP servers.

The target audience is a developer team that has heard of MCP and wants a running, observable example they can deconstruct and extend. The project includes VitePress documentation, an llms.txt file, and an OpenTelemetry integration for the Aspire Dashboard, all of which are details that a production team would need to add but that a learning sample can include as starting scaffolding.

Architecture: MCP Servers, Orchestrators, and Container Deployment

Each component in the system is a Docker container. The docker-compose.yml file defines the services: four MCP servers on ports 5001 through 5004, three orchestrator API services on ports 4000, 4001, and 4010, an Aspire Dashboard, and a web frontend. All of them are brought up together for local development.

The MCP servers map directly to the agents:

- mcp-customer-query on port 5001 handles preference extraction. - mcp-destination-recommendation on port 5002 handles destination suggestions. - mcp-itinerary-planning on port 5003 (Python, port 8000 inside the container) handles itinerary generation. - mcp-echo-ping on port 5004 is a test server that echoes input.

The orchestrator services are independent. api-langchain-js runs on port 4000, api-llamaindex-ts on port 4001, and api-maf-python on port 4010. Each orchestrator connects to the same MCP servers. Swapping orchestrators in production is a matter of pointing the client at a different API endpoint.

All components are deployed to Azure Container Apps using the Azure Developer CLI. The OpenTelemetry integration sends traces to the Aspire Dashboard, which provides visibility into agent invocations and inter-service latency.

Running the Application Locally for Free

The README describes a local preview path that uses Docker Model Runner to run an LLM without an Azure account. Before running the preview script, you need Git, Node.js, Docker Desktop with Docker Model Runner enabled, and PowerShell 7+ if you are on Windows.

The setup script (preview.sh on Linux and macOS, preview.ps1 on Windows) runs a dependency check, clones the repository, installs npm dependencies, downloads the Phi4 14B model (approximately 7.80 GB), builds the Docker images for all MCP servers, and configures the .env files.

The README includes an important hardware note: the Phi4 14B model requires at least 16GB of RAM and a modern CPU or GPU. GPU acceleration in Docker Model Runner is supported on macOS Apple Silicon and NVIDIA GPUs on Windows. If your machine cannot run the Phi4 model locally, the README points to docs/advanced-setup.md for using Microsoft Foundry instead.

For Azure deployment, the standard path uses the Azure Developer CLI (azd). The commands azd auth login, azd env new, and azd up handle authentication, environment creation, and provisioning. You will be asked to choose a region for most resources and a separate region for Azure OpenAI models, since not all models are available in all regions.

MCP Servers in Four Languages: What Each Approach Involves

One of the more concrete learning outcomes of this project is seeing how MCP servers are implemented across language stacks. The four MCP server implementations each use a different runtime:

The customer query MCP server uses one language runtime. The destination recommendation server uses another. The itinerary planning server is Python (port 8000 in the container, mapped to 5003 on the host). The echo ping server is Node.js (port 3000 in the container, mapped to 5004 on the host).

The docker-compose.yml shows that each server is built from its own Dockerfile in the packages/mcp-servers/ directory. The OTEL_SERVICE_NAME and OTEL_EXPORTER_OTLP_ENDPOINT environment variables in the docker-compose file configure OpenTelemetry for the customer query server, passing traces to the Aspire Dashboard on port 18889.

The README notes that MCP servers can be extended with new agents and tools by adding new packages in the packages/ directory and registering them in the docker-compose configuration. The project's modularity means adding a fifth agent does not require modifying any existing service.

Three Orchestration Options and Their Trade-offs

The three orchestrators are separately deployable services, each implementing the same travel agency coordination logic but using a different framework. LangChain.js and LlamaIndex.TS are TypeScript services. Microsoft Agent Framework is Python.

LangChain.js is a widely used JavaScript LLM framework with extensive documentation and community tooling. LlamaIndex.TS is the TypeScript port of LlamaIndex, which focuses on data connectors and structured retrieval. Microsoft Agent Framework is a newer Python framework from Microsoft designed for building multi-agent systems. Having all three in one repository lets a developer compare how the same coordination problem is expressed in each framework.

The choice of orchestrator does not affect the MCP servers. The MCP protocol is the abstraction layer between them. A team that already uses LangChain.js in production can adopt the LangChain.js orchestrator and ignore the other two, while still benefiting from the MCP server implementations in multiple languages.

The Aspire Dashboard provides observability across all three orchestrators. If you run all three simultaneously in local development, you can compare the traces and see how each framework sequences its agent invocations.

Limitations and What This Project Is Not

azure-ai-travel-agents does not book flights, hotels, or any travel service. It is a demonstration of agent coordination patterns, not a working travel application. The destination recommendations and itineraries it produces are generated by LLMs and have no connection to real availability data.

The local preview requirement of 16GB RAM is significant. Many developer laptops, particularly older ones, cannot run the Phi4 14B model. The README provides an alternative path through Microsoft Foundry, but that requires an Azure account and incurs cost.

The project uses multiple frameworks and four programming languages, which means the maintenance surface is wide. A breaking change in LangChain.js, LlamaIndex.TS, or the Microsoft Agent Framework SDK requires updates to the corresponding orchestrator service. The repository must track dependencies across TypeScript and Python ecosystems simultaneously.

The project does not currently have a production-hardening guide. Features like authentication, rate limiting, input validation, and secret rotation are absent from the reference implementation and must be added before any customer-facing deployment.

Maintenance and Licence

The last push to the repository was on 2026-09-28, indicating active development. The project carries no GitHub releases and uses main as the default branch.

The project is licensed under MIT. The CONTRIBUTING.md and SECURITY.md files provide guidance for code contributions and vulnerability reporting respectively.

The README links to a Microsoft Tech Community blog post and a Discord server for community support. The MCP for Beginners guide (github.com/microsoft/mcp-for-beginners) is linked as a companion resource for developers unfamiliar with the Model Context Protocol.

Editorial conclusion

azure-ai-travel-agents is a good starting point for developers who want to see MCP server implementation in Python, Node.js, Java, and .NET alongside three orchestration libraries in a single deployable project. It is a reference application, not a production travel booking system. Before adopting it as a foundation, verify that the local preview requirements (at least 16GB RAM for the Phi4 14B model) match your development machines, and confirm which orchestrator (LangChain.js, LlamaIndex.TS, or Microsoft Agent Framework) aligns with your team's existing stack.

Frequently asked questions

Is there an AI agent for travel?

azure-ai-travel-agents is a reference application that implements three AI agents for travel: one that understands customer preferences, one that recommends destinations, and one that plans itineraries. It is designed as a developer learning resource rather than a consumer travel product.

Does Azure have AI agents?

Azure provides infrastructure for building multi-agent AI systems. The azure-ai-travel-agents sample demonstrates three orchestration approaches (LangChain.js, LlamaIndex.TS, and Microsoft Agent Framework) deployed on Azure Container Apps, using Azure OpenAI for the language model backend.

What programming languages are used in azure-ai-travel-agents?

The MCP servers are implemented in Python, Node.js, Java, and .NET. The orchestrator services use TypeScript (LangChain.js and LlamaIndex.TS) and Python (Microsoft Agent Framework).

Official sources

  1. Azure-Samples/azure-ai-travel-agents on GitHub
  2. Issues
  3. License: MIT
  4. Project website
  5. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/azure-samples-azure-ai-travel-agents.svg)](https://hysenlabs.com/projects/azure-samples-azure-ai-travel-agents)