Skip to main content
Glama
nishankuu

Leave Management MCP Server

by nishankuu
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Leave Management MCP Server

An AI-powered leave management assistant built using Anthropic's Model Context Protocol (MCP). This server connects directly to Claude Desktop, enabling HR teams to query and manage employee leave through natural language — no dashboards, no forms, just conversation.

The Problem

HR teams in most organizations manage leave through static spreadsheets or rigid portals that require navigating multiple screens to answer simple questions like:

  • "How many leave days does Rahul have left?"

  • "Has Anjali taken any leave this quarter?"

  • "Apply 2 days of leave for Karan on April 17th and 18th"

These systems are slow, require training, and don't scale well for HR managers handling large teams.

Related MCP server: HR-Assist

The Solution

This project exposes leave management operations as MCP tools that Claude can call in real time. HR can simply open Claude Desktop and ask questions in plain English — Claude intelligently decides which tool to call, passes the right parameters, and returns a human-readable answer.

No UI. No SQL. No form submissions. Just conversation.

Demo

Check leave balance:

"What is the leave balance for E003?" → Rahul Verma has 15 leave days remaining.

Apply for leave:

"Apply leave for E007 on 2025-07-10 and 2025-07-11" → Leave applied for 2 day(s). Remaining balance: 17.

View leave history:

"Show me the leave history for E006" → Leave history for E006: 2024-12-31, 2025-01-02, 2025-01-03, ...

Tech Stack

Layer

Technology

AI Client

Claude Desktop

Protocol

Model Context Protocol (MCP)

Server Framework

FastMCP (Python)

Package Manager

uv

Language

Python 3.11

Data Layer

In-memory JSON (mock database)

Architecture

Claude Desktop (MCP Client)
        │
        │  MCP Protocol (stdio transport)
        ▼
  FastMCP Server — main.py
        │
        ├── Tool: get_leave_balance(employee_id)
        ├── Tool: apply_leave(employee_id, leave_dates)
        ├── Tool: get_leave_history(employee_id)
        └── Resource: greeting://{name}
              │
              ▼
    In-memory employee_leaves dictionary

How it works end-to-end:

  1. HR types a natural language query in Claude Desktop

  2. Claude identifies the right MCP tool based on the query

  3. Claude calls the tool with extracted parameters

  4. The Python function runs and returns the result

  5. Claude presents the result in a conversational response

Project Structure

my_mcp/
├── main.py              # MCP server — all tools and resources defined here
├── pyproject.toml       # Project metadata and dependencies
├── uv.lock              # Locked dependency versions for reproducibility
└── README.md            # This file

Getting Started

Prerequisites

Setup

# Clone the repo
git clone <your-repo-url>
cd my_mcp

# Install dependencies
uv sync

# Install the server into Claude Desktop
uv run mcp install main.py

# Restart Claude Desktop
# The LeaveManager tools will now appear in Claude

Mock Data

The server comes pre-loaded with 10 employees:

ID

Name

Leave Balance

E001

Amit Sharma

18 days

E002

Priya Mehta

20 days

E003

Rahul Verma

15 days

E004

Sneha Iyer

17 days

E005

Karan Patel

20 days

E006

Anjali Singh

12 days

E007

Vikram Nair

19 days

E008

Deepa Pillai

16 days

E009

Rohan Gupta

20 days

E010

Meera Joshi

11 days

Each employee starts with 20 days. Balance reflects days already taken.

MCP Tools Exposed

get_leave_balance

Returns the remaining leave balance for an employee.

  • Input: employee_id (string)

  • Output: Remaining days as a string

apply_leave

Applies leave for specific dates, deducting from balance and recording in history.

  • Input: employee_id (string), leave_dates (list of date strings)

  • Output: Confirmation with updated balance

get_leave_history

Returns all leave dates taken by an employee.

  • Input: employee_id (string)

  • Output: Comma-separated list of dates

What This Demonstrates

  • MCP Server Development — Building a production-pattern MCP server using FastMCP, exposing typed tools and resources that an AI client can discover and invoke

  • AI Tool Integration — Understanding how LLMs interact with external tools via structured protocols, including tool discovery, parameter extraction, and response handling

  • Python Project Structure — Using uv for dependency management, virtual environments, and reproducible builds with lockfiles

  • Protocol Design — Designing tool interfaces with clear docstrings that serve as tool descriptions for the LLM, following the principle that the docstring IS the API contract in MCP

Next Steps / Roadmap

  • Replace in-memory dict with a real database (PostgreSQL / SQLite)

  • Add leave approval workflow (manager approval tool)

  • Add leave type support (sick, casual, annual)

  • Add employee lookup by name instead of only by ID

  • Deploy server for remote access

Author

Built by Nishant Kumar as a hands-on exploration of Anthropic's Model Context Protocol and AI tool integration patterns.

Available Tools

3 tools
apply_leaveA
Apply leave for specific dates (e.g., ["2025-04-17", "2025-05-01"])
ParametersJSON Schema
NameRequiredDescriptionDefault
employee_idYes
leave_datesYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavioral disclosure. The example implies the tool creates or submits leave, which signals a write operation, but no details are given about side effects, required permissions, approval flows, or whether overlapping leave is handled. This is minimally adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with an example, which is perfectly concise. Every element earns its place: the verb, the object, the parameter hint, and the format example. No unnecessary words or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 required parameters, no output schema, and no annotations, the description covers the core action and one parameter's format but leaves 'employee_id' largely unexplained and omits any indication of return values, error handling, or behavioral caveats. It is complete enough for a straightforward action but not robust.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (parameters have no descriptions in the schema), so the description must compensate. The description adds meaning by showing the expected date format via example and implies the 'leave_dates' array structure. However, 'employee_id' is not elaborated beyond the schema title, missing an opportunity to explain its format or source.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: applying leave for specific dates, with a concrete example of the date format. It uses a specific verb+resource combination ('Apply leave') and distinguishes its action from the sibling tools (get_leave_balance, get_leave_history) which are read-only queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete usage example (the array of dates) but gives no guidance on when to use this vs. alternatives, nor are there any prerequisites or exclusions mentioned. The example implies usage context but lacks explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_leave_balanceA

Check how many leave days are left for the employee

ParametersJSON Schema
NameRequiredDescriptionDefault
employee_idYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries burden. It states read-only behavior ('Check'), which is clear. However, it doesn't disclose mutability (none), required permissions, or whether balance is real-time or cached. Adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence directly stating the tool's purpose with no filler. Highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is simple (1 param, no output schema). The description suffices for basic use, but for a balance check tool, details like output format (days? hours?) or constraints (leave types) would enhance completeness. Meets minimum viability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with one parameter. Description doesn't explain 'employee_id' beyond what the schema shows (employee ID). Baseline 3 is appropriate as schema is minimal, but description adds no parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks remaining leave days for an employee, using a specific verb ('Check') and resource ('leave days'). It distinguishes from siblings: 'apply_leave' involves submission, 'get_leave_history' shows past records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing current balances, but no explicit guidance on when not to use or alternatives. Given siblings, context hints (e.g., don't use for history or applying) are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_leave_historyC

Get leave history for the employee

ParametersJSON Schema
NameRequiredDescriptionDefault
employee_idYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavior. It fails to state whether this is a read-only or mutating action, what data is returned (e.g., list of leave records, dates, statuses), or any limitations (e.g., date range, employee scope). The description is insufficient for a tool with zero annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise, but lacks any structured detail. It is front-loaded with the key action, yet important behavioral and usage information is missing, making it under-specified rather than appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one required parameter, no output schema, and no annotations, the description is highly incomplete. It does not explain what 'leave history' contains, how to interpret results, or any constraints. A simple tool might be acceptable with more detail, but this falls short.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and there is no explanation of the 'employee_id' parameter beyond the schema. The description adds no meaning, such as format (e.g., UUID, email), required access, or how the ID relates to the employee. For a required parameter, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get leave history for the employee', indicating a read operation on leave records. It uses a specific verb ('get') and resource ('leave history'), but does not differentiate from siblings like 'get_leave_balance' which also reads but returns balance data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs. alternatives. For example, it doesn't clarify that 'apply_leave' is for creating requests or that 'get_leave_balance' shows remaining days. The description gives no context on appropriate use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation4/5

Each tool targets a distinct aspect of leave management: balance, application, and history. There is no overlap in purpose, though descriptions are somewhat minimal. Overall, an agent can easily tell them apart.

Naming Consistency4/5

All three tools follow a verb_noun pattern (get_leave_balance, apply_leave, get_leave_history). The verb 'get' is used for two tools, which is acceptable since they retrieve different resources. No mixed conventions or chaotic naming.

Tool Count3/5

Three tools is on the low side for a typical MCP server, but for a focused leave management domain it covers the core actions. It feels slightly thin, but each tool earns its place. The count is borderline but justifiable.

Completeness2/5

The server provides basic leave operations (check balance, apply, view history) but lacks essential actions like cancel/withdraw a leave request, approve/reject (for managers), or update a pending request. These gaps could cause agent failures in real workflows.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nishankuu/mcp_project'

If you have feedback or need assistance with the MCP directory API, please join our Discord server