LeaveManager
# LeaveManager – MCP Server with Claude Integration
LeaveManager is a custom **Model Context Protocol (MCP) server** built using **FastMCP**.
It allows Claude to interact with a backend **Leave Management System** using natural language.
This project demonstrates how Claude can automatically select and execute backend tools based on user queries.
---
## 🚀 Features
- Check employee leave balance
- Apply leave for specific dates
- View leave history
- In-memory state management
- Claude Desktop integration via MCP
- Automatic tool selection from natural language
---
## 🧠 Tech Stack
- Python 3.10+
- FastMCP
- MCP CLI
- Claude Desktop (for tool invocation)
- uv (Python package manager)
---
## 📂 Project Structure
my-first-mcp-server/
│
├── main.py
├── pyproject.toml
├── README.md
├── .gitignore
├── uv.lock
└── .venv/
---
## 🛠️ MCP Tools
### 1️⃣ `get_leave_balance`
Checks remaining leave days for an employee.
**Input:**
- `employee_id` (string)
---
### 2️⃣ `apply_leave`
Applies leave for given dates and updates balance.
**Input:**
- `employee_id` (string)
- `leave_dates` (list of YYYY-MM-DD)
---
### 3️⃣ `get_leave_history`
Returns all leave dates taken by an employee.
**Input:**
- `employee_id` (string)
---
## 💡 Example Claude Queries
- “Check leave balance for employee E001”
- “Apply leave for employee E001 on 2025-04-17 and 2025-05-01”
- “Show leave history for employee E001”
Claude automatically selects and executes the correct MCP tool.
---
## ⚠️ Important Note on Data Storage
- This project uses **in-memory storage**
- Data resets when the MCP server restarts
- This is intentional for simplicity
- Can be extended with SQLite for persistence
---
## ▶️ Running Locally (Without Claude)
```bash
uv run main.py
🎯 Learning Outcomes
Built a real MCP server
Exposed backend tools to Claude
Understood stateful MCP behavior
Integrated Python backend with LLM tool calling
📌 Future Improvements
SQLite persistence
Date validation & duplicate checks
Employee creation & reset tools
FastAPI + MCP hybrid architecture
🧑💻 Author
Uma Maheswara Rao
Aspiring AI Engineer / Data AnalystTDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: apply_leave is for submitting new leave requests, get_leave_balance shows remaining leave days, and get_leave_history retrieves past leave records. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun naming pattern (apply_leave, get_leave_balance, get_leave_history) with clear, descriptive names. The pattern is uniform throughout, enhancing readability and predictability.
With only 3 tools, the server feels thin for a leave management domain, as it lacks operations like updating or canceling leave requests, viewing team leave calendars, or approving/rejecting leave. While the tools cover basic needs, the scope is borderline minimal.
The tool set has significant gaps for a leave management system. It includes apply, balance, and history but misses critical operations such as update_leave, delete_leave, list_pending_requests, or approve_leave. This incomplete coverage will likely cause agent failures in real-world workflows.