The latest evolution of my NPS Hikes project is an MCP server. In many ways, it was the natural next step.
- I first built a conventional software interface: a FastAPI backend and a Streamlit client.
- I then added an NLQ endpoint so users could ask for results in natural language instead of reading the API docs (or using the Streamlit filters manually).
However, the local LLM doing the parsing in the NLQ layer has a practical limit. Adding an MCP server, on the other hand, enabled me to transfer the job of understanding user intent to stronger hosted assistants, while keeping my own system responsible for grounded data access.
The value of an MCP server
MCP provides a standard way to publish my app’s capabilities so that AI clients can use them. While the Streamlit app is the best interface for human users, MCP is the best interface for AI clients.
The MCP server simplified the app’s natural language layer. When the NLQ endpoint receives a user query:
- My app calls Ollama.
- My app parses the tool call.
- My app dispatches to the backend logic.
- My app returns the result.
However, the MCP server lets me shift a lot of this responsibility to MCP-compatible AI clients. When an AI client with access to my MCP server receives a user query:
- The AI client chooses the tool call.
- The MCP server receives structured arguments.
- The MCP server dispatches to the backend logic.
- The tool result goes back to the AI client.
- The AI client answers the query, drawing on the result.
This is a much cleaner architecture for AI use. If accepting the external dependency, my app no longer needs to be the conversational layer. It just needs to expose trustworthy capabilities.
Testing the MCP server
The MCP inspector is a handy way to first test that the server can expose the correct tools and resources.
Then try it out with a real assistant like Claude:
