F
licenseNot graded
qualityD
maintenanceA Model Context Protocol server that enables querying attendance information and managing employee leave requests, overtime requests, and schedules.
HR MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@HR MCP Serversearch for employees in the Engineering department located in Seattle"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
HR MCP Server
A Model Context Protocol (MCP) server for HR operations built for use with Claude Desktop.
https://github.com/user-attachments/assets/4cb89115-daf2-4647-81d2-aadd9e0dd29e
Overview
This server implements the Model Context Protocol to provide Claude with structured access to employee data and HR operations.
The HR MCP Server enables Claude to:
Look up detailed employee information
Search for employees by various criteria
Submit and manage global leave requests
Translate text with HR/HCM context awareness
For a detailed architectural overview, see ARCHITECTURE.md.
Related MCP server: LeaveManager
Tools
The server provides the following tools to Claude:
1. get_employee_info
Retrieves detailed information about a specific employee by ID, including personal details, employment information, skills, benefits, and more.
// Example usage:
get_employee_info({ employee_id: "E001" })
// With sensitive information:
get_employee_info({ employee_id: "E001", include_sensitive: true })2. search_employees
Search for employees by various criteria with flexible matching options. Supports searching by name, department, skills, location, and many other fields.
// Basic search:
search_employees({
query: { department: "Engineering" }
})
// Advanced search:
search_employees({
query: {
location: "Seattle",
performance_rating: 5
},
options: {
sort_by: "hireDate",
output_format: "detailed"
}
})
// Search with sensitive information:
search_employees({
query: { salary_min: 100000 },
options: { include_sensitive: true }
})3. request_global_leave
Submit global leave requests for employees traveling to multiple countries, with approval chains and compliance reminders.
// Basic request:
request_global_leave({
employee_id: "E002",
start_date: "2025-05-01",
end_date: "2025-05-15",
reason: "Family vacation",
countries: ["USA", "UK"]
})
// With custom contact info:
request_global_leave({
employee_id: "E002",
start_date: "2025-05-01",
end_date: "2025-05-15",
reason: "Family vacation",
countries: ["USA", "UK"],
contact_info: {
email: "bob.vacation@example.com",
phone: "+1-555-123-4567"
}
})4. Translation Prompt: translate_text
Translates text from any language to a specified target language with automatic source language detection and special focus on HR/HCM terminology.
// Basic translation:
translate_text({
text: "Les employés doivent soumettre leurs feuilles de temps avant la fin de la période.",
target_language: "English"
})The translation system handles HR-specific terminology with contextual awareness, preserving the technical meaning of terms like "benefits," "period," "check," "position," etc., which have special meanings in Human Capital Management contexts.
Installation
# Clone the repository
git clone https://github.com/yourusername/hr-mcp-server.git
cd hr-mcp-server
# Install dependencies
npm install
# Build the project
npm run buildUsage
Start the server:
npm startConnect Claude Desktop to the server by selecting "Local Tool (via stdio)" as the tool type and using the path to the server's start script.
Access employee data and HR tools through Claude's interface.
Development
Source code is in
/srcdirectoryEmployee data is stored in
/src/data/employees.tsThe server uses TypeScript with strict typing
To run in development mode:
npx ts-node-esm src/index.tsTech Stack
TypeScript
Node.js
@modelcontextprotocol/sdk - MCP SDK for JavaScript/TypeScript
Zod - TypeScript-first schema validation
Code Structure
The server is organized with a focus on clean, maintainable code:
Centralized logging - Consistent JSON-RPC formatted logging
Tool-based architecture - Each tool has a clear responsibility
Schema validation - Strong typing with Zod for all inputs
Error handling - Comprehensive validation with clear error messages
Documentation - Inline comments explaining complex logic
License
MIT
Copyright (c) 2024
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Available Tools
3 toolsget_employee_infoD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| employee_id | Yes | The ID of the employee to retrieve information for | |
| include_sensitive | No | Whether to include sensitive information like SSN (default: false) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_global_leaveD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contact_info | No | Contact information during leave | |
| countries | Yes | Countries for which leave is being requested (e.g., ["USA", "UK"]) | |
| employee_id | Yes | The ID of the employee requesting leave | |
| end_date | Yes | End date of the leave (YYYY-MM-DD) | |
| reason | Yes | Reason for the leave request | |
| start_date | Yes | Start date of the leave (YYYY-MM-DD) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_employeesD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Search options | |
| query | Yes | Search parameters - provide at least one field |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
D1.8/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: get_employee_info retrieves specific employee details, request_global_leave handles leave requests, and search_employees finds employees based on criteria. There is no overlap in functionality, making tool selection straightforward.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (get_employee_info, request_global_leave, search_employees). The naming is uniform and predictable, with no deviations in style or convention.
Tool Count2/5
With only 3 tools, the server feels thin for an HR domain, which typically requires more operations like updating employee info, managing leave approvals, or handling payroll. The count is too low for comprehensive HR functionality.
Completeness2/5
The tool set is severely incomplete for an HR server. It lacks essential CRUD operations (e.g., update or delete employee info), leave management workflows (e.g., approve/reject leave), and other HR functions like onboarding or performance reviews, leading to significant gaps.
Maintenance
ActivityInactive
ResponsivenessNo issues
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
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Related MCP Servers
- FlicenseBqualityDmaintenanceA Model Context Protocol server that enables users to manage employee leave through natural language. It provides tools to check leave balances, apply for leave, and view leave history via Claude integration.3
- AlicenseAqualityBmaintenanceA Model Context Protocol server that enables Claude to interact with a Lucca instance to list employees, departments, and view absences in natural language.3MIT
- FlicenseDqualityCmaintenanceAn AI-powered HR assistant that automates employee management, leave handling, ticket creation, meeting scheduling, and email notifications through natural language conversations using the Model Context Protocol.11
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gabrielrojasnyc/hr-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server