An RAG and MCP agent that performs academic tasks, not just answers about them
A natural-language request had to end in a system action, not only a reply. For an agent that acts, a wrong execution is more dangerous than a wrong answer.
- Next.js
- Spring Boot
- FastAPI
- LangChain
- Vector DB
- RAG
- MCP
- JWT
- MariaDB
Specification
- Team
- Four people
- Period
- 2025
- Frontend
- Next.js
- Backend
- Java Spring Boot, REST API
- Agent server
- Python FastAPI, LangChain, MCP
- Data
- Vector DB for regulation retrieval, MariaDB
- Role
- Frontend development, end-to-end service flow design, interface alignment across the team
Context
Chatbots that answer questions about academic rules are common. But what a user usually wants is the task done, not explained — being told the answer and then having to go do it yourself solves half the problem.
So the request had to carry through to a real system action.
Approach
Academic regulations and guidance went into a Vector DB, and RAG retrieves the relevant rule before the model answers. Regulations are retrieved, not remembered.
Tools are exposed through an MCP server; the agent interprets the request, selects the tool it needs, and executes it.
Alongside the frontend I worked out the call relationships, execution order, authentication, user state and exception handling between the frontend, Spring Boot and the FastAPI agent. Where three servers meet, blurred responsibility makes failures impossible to trace.
During testing the agent modified data using a wrong condition. I did not stop at fixing the condition. For an agent that acts, this is a structural class of failure, so tool execution permissions, execution scope, task conditions, user permissions, logging, failure handling and recoverability were all reviewed again.
System
The path does not end at an answer; it ends at a tool call.
A request passes through Next.js to the Spring Boot API and on to the FastAPI agent. The agent retrieves the relevant regulation from the Vector DB, the LLM selects the tool, and the MCP tool performs the actual system operation.
Boundaries
- The agent server implementation and model-related work belonged to teammates. I owned the frontend, the end-to-end service flow, and the interfaces between servers.
- No model was trained or fine-tuned. What was used is an LLM API and a retrieval structure.
- Permissions, scope, logging and recovery were reviewed and written down; I do not claim all of them were built out to completion.