Enables sending HR-related emails, such as welcome emails and manager notifications, through Gmail SMTP.
Click on "Deploy 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 Assist MCP Server Onboard a new employee named Emma and assign Liam as manager."
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 Assist is an AI-powered HR automation agent that uses Claude Desktop and MCP tools to handle tasks like onboarding, leave management, meeting scheduling, and ticket creation.
HR Assist is an agentic AI-powered HR automation system built using Claude Desktop, MCP (Model Context Protocol), and Python.
Claude Desktop acts as the AI agent and MCP client, understanding user requests and deciding which HR actions need to be performed. The MCP server exposes HR operations as tools and connects Claude with the HRMS components.
The system includes the following managers:
Employee Manager
Leave Manager
Meeting Manager
Ticket Manager
Related MCP server: HR-Assist
The user provides an HR request through Claude Desktop. Claude understands the request, selects the required MCP tools, and executes the appropriate actions through the MCP server.
For example, when onboarding a new employee, the system can add the employee, send a welcome email, notify the manager, raise a laptop ticket, schedule an introduction meeting, and handle leave-related actions.
The project provides tools for:
š¤ Adding and retrieving employees
šļø Managing leave
š§ Sending emails
š Scheduling meetings
š« Creating HR/IT tickets
š Supporting employee onboarding workflows
hrms/
āāā employee_manager.py
āāā leave_manager.py
āāā meeting_manager.py
āāā ticket_manager.py
āāā schemas.py
images/
āāā architecture.png
āāā tool_selection.png
āāā prompt_inputs.png
āāā meeting_time_selection.png
āāā onboarding_summary.png
server.py
emails.py
utils.py
pyproject.toml
README.mdš Python
š¤ Claude Desktop
š Model Context Protocol (MCP)
š¦ uv
āļø Gmail SMTP
š¢ HRMS Components
Clone the repository and install the dependencies:
uv syncRun the MCP server:
uv run python server.pyConfigure the MCP server with Claude Desktop and start interacting with HR Assist.
User:
Onboard a new employee named Likhitha and assign Tony Sharma as the manager.
HR Assist:
ā Employee added
ā Welcome email sent
ā Manager notified
ā Laptop ticket created
ā Introduction meeting scheduled
ā Leave status checkedHR Assist demonstrates how agentic AI + MCP tools can automate real-world HR workflows by allowing an AI agent to understand requests, select tools, and execute multiple actions autonomously.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| emp_name | Yes | ||
| manager_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| emp_id | Yes | ||
| leave_dates | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| emp | Yes | ||
| item | Yes | ||
| reason | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| emp_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| emp_id | Yes | ||
| emp_name | Yes | ||
| meeting_dt | Yes | ||
| manager_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| subject | Yes | ||
| to_emails | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_employeeapply_leavecreate_ticketget_employee_detailsget_leave_historyschedule_meetingsend_emailScored across 7 tools
Tool names map to fairly distinct actions (employee CRUD-ish, email, ticketing, meetings, leave), so an agent can mostly tell them apart. However, with no descriptions provided, boundaries like add_employee vs get_employee_details and the generic send_email/create_ticket/schedule_meeting are only inferable from names, leaving mild ambiguity.
All seven tools follow a clean snake_case verb_noun pattern (add_employee, get_employee_details, apply_leave, get_leave_history, etc.). No mixing of conventions or vague standalone verbs.
Seven tools is well-scoped for an HR assistant spanning employee records, leave, and administrative actions. Each tool appears to earn its place without redundancy.
The surface covers create/read for employees and full leave apply/history, but lacks update_employee, delete/offboard, or a list_employees operation, creating dead ends in the employee lifecycle. Generic email/ticket/meeting tools are present but no supporting read/list operations for them.
Let AI agents query data and act across all your business apps via MCP.
Build and manage AI-native customer support agents from Claude or any MCP client.
Zapier MCP connects AI tools like Claude, ChatGPT, and Cursor to over 8,000 apps and 30,000+ actions, enabling AI to perform real-world tasks such as sending messages, searching data, scheduling events, and updating records. It acts as a translator between AI tools and apps, handling authentication, rate limits, and retries automatically, transforming AI from a conversational tool into a functional extension of your business stack.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
