Why I Built It
Most tutorials explain concepts in isolation. MCP servers. Docker. GitHub Actions. Azure deployment. But I wanted to see them work together end-to-end. What does a real, deployed MCP server look like? How does GitHub Actions actually automate deployment? What’s the full flow from code to running agent?
So I picked Museums Victoria’s public API (1.15 million collection records, well-documented, no auth required) and built Curator as a learning project. Eight semantic tools. Deployed to Azure. Connected to Copilot Studio. The whole stack.
The Real Difference: With MCP vs. Without
Let me show you why MCP matters by walking through the same scenario two different ways.
Scenario: User Asks “Show me dinosaurs from Victoria”
WITHOUT MCP (Direct API Integration)
Copilot Studio has to understand and handle everything. It needs to know which endpoint to call (/search vs /items?). What parameters each accepts. How to format the request. Make the API call. Parse the JSON. Handle pagination (what if there are 500 results?). Handle errors (API timeout? 404?). Extract relevant fields. Format for display.
User: "Show me dinosaurs from Victoria" ↓Copilot: "Which endpoint do I use? /search? /specimens? What parameters do I need? How do I handle pagination? What if the API fails? How do I format the response?" ↓Copilot: Constructs request, calls API, parses response, handles errors, formats for display ↓User gets results (if everything works)
Problems: If the API changes, Copilot breaks. Error handling is fragile. Every consumer of the API (mobile app, different agent, web app) reimplements the same logic. It’s scattered, hard to maintain.
WITH MCP (Semantic Tools)
Copilot Studio just calls a tool. It doesn’t care about API complexity. The MCP server handles everything.
User: "Show me dinosaurs from Victoria" ↓Copilot: "I have a tool called search_collections. Call search_collections(query='dinosaur')" ↓MCP Server handles: - Authentication - API endpoint routing - Parameter validation - Pagination - Error handling - Response parsing ↓Copilot: "Got clean data. Format it for display" ↓User gets results (reliably)
Advantages: Copilot doesn’t care about API complexity. If the API changes, you update the server once (not every consumer). Error handling is centralized. Pagination, caching, rate limiting all built in. Copilot can reason about what tools to use because they have semantic meaning.
What I Learned
MCP servers are simpler than they sound. You define tools. Map them to API endpoints. Handle responses. Deploy it. That’s it. The architecture is elegant because it’s minimal.
GitHub Actions CI/CD actually works. Push code → GitHub builds Docker image → pushes to Azure Container Registry → deploys to running container. No manual steps. No clicking dashboards. It just happens.
Semantic tools matter more than raw APIs. When Copilot Studio can call search_collections(query, filters) instead of figuring out endpoints, everything changes. The agent can reason about what tools to use.
Deployment infrastructure is mature and cheap. Azure Container Instance costs ~$20/month. GitHub Actions is free. You can deploy production-grade infrastructure for nothing.
Why This Pattern Scales
This isn’t just for museums APIs. This is how enterprise AI actually works:
- Salesforce integrates with AI through semantic layers, not raw endpoints
- SAP connects to agents through named tools, not API calls
- Netflix uses this pattern for data access
- Your company probably does too
You’re not learning something niche. You’re learning production architecture.
The Full Source
Everything is on GitHub: github.com/ifiecas/curator-mcp
The repo includes:
- MCP server code (Python)
- Dockerfile
- GitHub Actions workflows
- Deployment documentation
- Everything needed to understand and replicate
How to Learn the Same Way
Pick any public API that interests you. Museums Victoria, PokéAPI, SpaceX API, OpenWeatherMap. Fork Curator. Swap the endpoints. Deploy it. That’s your learning project.
By doing this once, you’ll understand:
- How MCP servers work (not conceptually, but actually)
- How GitHub Actions deploys code automatically
- How to containerize Python applications
- How to connect infrastructure to Copilot Studio
- The full end-to-end flow from code to deployed agent
And here’s the thing: once you’ve done it once, doing it again takes an hour. Different API, same pattern. These skills transfer.
Why Learning by Building Works
Reading about MCP servers is fine. Actually building one is different. You hit real problems. You debug real errors. You see what works and what doesn’t. That’s where understanding lives.
And Curator is small enough to understand completely, but real enough to feel professional. It’s not a toy project. It’s production code. You can learn from it.
Actually Getting Started
- Clone or fork Curator → github.com/ifiecas/curator-mcp
- Read the README (walks through the architecture)
- Pick a different API you want to learn with
- Adapt Curator’s pattern (same tool structure, different endpoints)
- Deploy it (follow the docs in the repo)
- Connect it to Copilot Studio
One afternoon. One deployed MCP server. Complete understanding of how modern AI infrastructure works.
The Payoff
You won’t just understand MCP servers conceptually. You’ll have built, deployed, and integrated one. You’ll know exactly what’s happening at every step. You’ll be able to do it again for a different API in an hour.
When someone asks “why build an MCP server instead of calling the API directly?” you won’t have a theoretical answer. You’ll have lived experience. You’ll know the difference between fragile and professional. Between scattered logic and centralized control.