Optional Gmail integration for sending welcome and notification emails to employees and managers using a Gmail account with app password.
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 Assist MCP Server Onboard a new employee named Riya reporting to Sarah Johnson"
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.
Agentic HR assistant that exposes employee, leave, meeting, ticket, and email tools over the Model Context Protocol (MCP). Designed to automate onboarding workflows via an MCP client such as Claude Desktop.
Use these when creating a new employee (manager_id can be ID or name):
ID | Name | Role | Department |
E001 | Sarah Johnson | VP Engineering | Engineering |
E002 | Michael Chen | VP Product | Product |
E003 | David Wilson | Engineering Manager | Engineering |
E006 | Emily Kim | Product Manager | Product |
E009 | Priya Nair | HR Manager | HR |
Other sample staff: Tony Sharma (E004), James Rodriguez (E005), Carlos Mendez (E007), Lisa Wong (E008), Aisha Khan (E010), Rohan Mehta (E011), Neha Kapoor (E012).
Examples:
add_employee("Riya Shah", manager_id="E001", email="riya.shah@atliq.com")
add_employee("Riya Shah", manager_id="Sarah Johnson")
add_employee("Riya Shah") # defaults manager to E001Call list_managers or list_employees tools to see the full directory.
Related MCP server: HR-ASSIST
Add / look up employees
Leave balance, apply leave, leave history
Schedule / list / cancel meetings
Create and manage IT/HR tickets
Optional Gmail sending for welcome / manager notifications
Built-in onboarding prompt: onboard_new_employee
Install uv (recommended) or use pip.
From this directory:
uv syncOr with pip:
python -m venv .venv
.venv\Scripts\activate
pip install -e .Copy env values:
copy sample.env .envOptional (for real email):
CB_EMAIL=your@gmail.com
CB_EMAIL_PWD=your_gmail_app_passwordLeave blank to run without email (send_email will skip and report what it would send).
uv sync
uv run streamlit run streamlit_app.pyOpens at http://localhost:8501 with tabs for Directory, Onboard, Leave, Tickets, Meetings, Email, and Lookup.
Local .env:
CB_EMAIL=yourgmail@gmail.com
CB_EMAIL_PWD=your_16_char_app_passwordStreamlit Cloud → Settings → Secrets:
CB_EMAIL = "yourgmail@gmail.com"
CB_EMAIL_PWD = "your_16_char_app_password"Use a Gmail App Password (not your normal password).
Push this folder to a GitHub repo (include streamlit_app.py and requirements.txt).
Go to share.streamlit.io → New app.
Select the repo, set Main file path to streamlit_app.py.
Deploy. You’ll get a public URL like https://your-app.streamlit.app.
uv run python run_local.pyThis seeds dummy HR data and runs an onboarding-style flow through the same managers used by the MCP tools.
uv run python server.pystdio transport waits for an MCP client. To inspect tools interactively:
npx @modelcontextprotocol/inspector uv run python server.pyEdit Claude Desktop claude_desktop_config.json and point command / --directory at this project folder:
{
"mcpServers": {
"hr-assist": {
"command": "uv",
"args": [
"--directory",
"C:\\Users\\omkar\\Documents\\Project\\AI\\HR Assist (MCP Server)",
"run",
"python",
"server.py"
],
"env": {
"CB_EMAIL": "YOUR_EMAIL",
"CB_EMAIL_PWD": "YOUR_APP_PASSWORD"
}
}
}
}In Claude Desktop, use the onboard_new_employee prompt or ask naturally, for example:
Onboard a new employee named Riya reporting to Sarah Johnson
What is Tony Sharma's leave balance?
Create a laptop ticket for E009
server.py MCP tools + onboarding prompt
run_local.py Local demo without MCP client
emails.py SMTP helper
utils.py Dummy data seeder
hrms/ Employee, leave, meeting, ticket managers + schemasAdd a new employee to the HRMS system.
:param emp_name: New employee full name :param manager_id: Manager employee ID OR manager name. Examples: "E001", "Sarah Johnson", "David Wilson". Defaults to E001 (Sarah Johnson) if omitted. :param email: Employee email. If empty, auto-generated as name@atliq.com :return: Confirmation message with new employee ID
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| emp_name | Yes | ||
| manager_id | No | E001 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses auto-generation of email, default values for manager_id, and acceptable formats. However, it lacks details on permissions, error handling, or side effects.
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?
The description is concise and well-structured, with a clear purpose sentence followed by parameter documentation and return value. Every sentence adds value without redundancy.
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?
The description covers basic functionality, parameter semantics, and return value. However, it lacks information on error conditions, prerequisites (e.g., manager existence), or any constraints (e.g., duplicate names), leaving gaps for a mutation tool.
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?
Schema description coverage is 0%, but the description fully compensates by providing clear descriptions for each parameter, including examples for manager_id and auto-generation rule for email. This adds significant meaning beyond the schema's type/default.
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?
The description clearly states 'Add a new employee to the HRMS system,' specifying the action (add) and the resource (employee). It distinguishes from sibling tools like list_employees and get_employee_details.
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?
No guidance is given on when to use this tool versus alternatives like create_ticket or when not to use it. The description only states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply for leave for an employee. :param emp_id: Employee ID :param leave_dates: List of leave dates :return: Leave application status message
| 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?
No annotations provided, so the description carries full burden. 'Apply for leave' implies a write/mutation operation, but no behavioral traits are disclosed (e.g., does it update a database, send notifications, require manager approval?). The description does not describe side effects or system impacts.
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?
The description is very short (one sentence plus docstring-like param/return). No wasted words, but could be more informative without becoming verbose. Front-loading is fine.
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?
Given the tool's simplicity (2 required params) and existence of sibling tools, the description is incomplete. It lacks details on what happens upon success/failure, required permissions, and how leave_dates should be formatted. The output schema exists but is not shown; the description's return note is vague.
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?
Schema coverage is 0%, so description must add meaning. It lists param names ('emp_id', 'leave_dates') but adds no format, constraints, or examples. The leave_dates array lacks item type or date format, leaving ambiguity. The return value is vaguely described as 'Leave application status message'.
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?
The description 'Apply for leave for an employee' is nearly a tautology of the tool name 'apply_leave'. It adds minimal new information (specific verb+resource) but does not help distinguish from siblings like 'get_leave_history' or 'get_employee_leave_balance', beyond the obvious action difference.
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?
No guidance on when to use this tool versus alternatives (e.g., when to apply leave vs. check balance or history). No mention of prerequisites, restrictions, or scenarios where this tool is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a scheduled meeting for an employee. :param employee_id: Employee ID :param meeting_datetime: Date and time of the meeting in python datetime format :param topic: Topic of the meeting (optional) :return: Confirmation message
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| employee_id | Yes | ||
| meeting_datetime | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only mentions return of confirmation message. No disclosure of side effects, cancellation policies, or impact on other systems. Additionally, the description claims topic is optional while schema requires it, creating confusion.
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?
Short but uses unnecessary docstring formatting ('param', 'return'). Adequately concise but could be cleaner.
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?
Given no annotations, the description is incomplete. It omits prerequisites (meeting existence), cancellation consequences, and the contradiction on topic weakens reliability.
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?
With 0% schema coverage, the description adds minimal value: employee_id is trivial, meeting_datetime gives format but no constraints, topic is incorrectly marked optional. No explanation of how these parameters identify a meeting.
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?
Clearly states 'Cancel a scheduled meeting' with specific verb and resource. Distinguishes from siblings like schedule_meeting (opposite) and get_meetings (different action).
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?
No explicit when-to-use or alternatives given; the cancel action is implied but lacks context like prerequisites or when not to use (e.g., meeting already passed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a ticket for buying required items for an employee. :param emp_id: Employee ID :param item: Item requested (Laptop, ID Card, etc.) :param reason: Reason for the request :return: Confirmation message
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | ||
| emp_id | Yes | ||
| reason | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Create a ticket' without mentioning side effects, permissions, idempotency, or error conditions. The return value is implied by the param docs but not explicitly stated in the 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?
The description is concise: one sentence plus param docs. It avoids fluff but the param docs are integrated into the description text, which is acceptable. It is front-loaded with the core action.
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?
Given the output schema exists, return value details are covered. However, the description lacks context about the created ticket's initial status, how to reference it later, or what happens if the employee or item is invalid. For a simple creation tool, it is adequate but could be more complete.
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?
The description includes param docs (:param emp_id: Employee ID, etc.), adding meaning beyond the schema's minimal titles. However, the descriptions are sparse: 'Employee ID' restates the name, 'Item requested (Laptop, ID Card, etc.)' gives examples but no constraints, and 'Reason for the request' is generic. This partially compensates for the 0% schema description coverage.
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?
The description clearly states the tool's purpose: 'Create a ticket for buying required items for an employee.' It uses a specific verb ('create') and resource ('ticket'), and the context of employee item purchase distinguishes it from sibling tools like list_tickets or update_ticket_status.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. For example, it doesn't specify that an employee must exist in the system or that the item should be valid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get employee details by name (or partial name). :param name: Name of the employee, e.g. "Tony" or "Sarah Johnson" :return: Employee details
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Get employee details' without specifying what details are returned, whether it's case-sensitive, or behavior on no match. Output schema exists but description doesn't reference it.
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?
Very short and front-loaded. Two lines cover purpose and parameter. However, docstring style adds a bit of redundancy with the schema.
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?
For a simple tool with one param and an output schema, the description is adequate but not thorough. Missing behavioral context like null returns or fuzzy matching. Siblings like list_employees hint at a different use case.
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?
Schema description coverage is 0%. Description adds meaning by explaining the 'name' parameter as employee name (full or partial) with examples, but lacks details on matching rules or format.
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?
Description clearly states the verb 'Get', resource 'employee details', and specifies searching by name or partial name. This distinguishes it from siblings like list_employees (which lists all) and add_employee.
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?
Implies use when you have a name/partial name to look up, but lacks explicit guidance on when not to use (e.g., comparing with list_employees) or prerequisites. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the leave balance of an employee. :param emp_id: Employee ID :return: Leave balance message
| 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?
With no annotations, the description fails to disclose behavioral traits like read-only nature, authentication requirements, or side effects. It does not indicate that this is a safe, non-destructive operation.
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?
The description is very concise but lacks structure. It is front-loaded with the main action, but the param and return documentation are minimal and could be better formatted for readability.
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?
Despite low complexity (one parameter) and an existing output schema, the description does not explain the return value beyond a vague 'Leave balance message'. It omits details about what fields the response contains, which is critical for an agent to interpret the result.
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?
The description adds a brief explanation for the sole parameter 'emp_id' (Employee ID), which is slightly more descriptive than the schema's title 'Emp Id'. However, schema description coverage is 0%, so the description provides little additional value beyond stating the obvious.
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?
The description clearly states the tool retrieves the leave balance of an employee, which distinguishes it from sibling tools like apply_leave (applies leave) and get_leave_history (retrieves historical records). However, it is somewhat vague about what exactly 'leave balance' includes.
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?
No guidance on when to use this tool vs alternatives such as get_leave_history or apply_leave. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the leave history of an employee. :param emp_id: Employee ID :return: Leave history message
| 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?
No annotations provided, so description must fully disclose behavior. It only says it returns a 'Leave history message' with no detail on format, content, or side effects (e.g., mutation, auth requirements). Minimal behavioral context.
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?
Short but includes redundant docstring-style parameter documentation after the purpose statement. Could be more front-loaded and eliminate the param line since the schema already defines emp_id.
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?
Despite presence of an output schema, the description is incomplete. Lacks usage guidance, behavioral details, and parameter semantics. Does not inform the agent about what constitutes valid input or expected output beyond a vague 'message'.
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?
Schema description coverage is 0%, so description must add value. It only restates the parameter name and type (':param emp_id: Employee ID'), essentially duplicating the schema. No additional meaning like format, constraints, or examples.
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?
Clearly states 'Get the leave history of an employee', using a specific verb and resource. Distinguishes from siblings like get_employee_leave_balance (balance vs history) and apply_leave (application vs retrieval).
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?
No guidance on when to use this tool versus alternatives. Does not state prerequisites or contexts where it should or should not be used. The description only states what it does, not when or when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of meetings scheduled for an employee. :param employee_id: Employee ID :return: List of meetings
| Name | Required | Description | Default |
|---|---|---|---|
| employee_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states it returns a list, without details on sorting, date range, or completeness. This is insufficient for a read operation.
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?
The description is short (two sentences plus docstring), but the docstring largely repeats the first sentence. Could be more concise and front-loaded.
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?
Despite having an output schema, the description does not explain what a 'meeting' contains (e.g., time, participants). The single parameter lacks detail, making the tool harder to use correctly.
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?
Schema coverage is 0%, but description only repeats 'Employee ID' for the parameter. It adds no format, source, or validation details. The return type is vague.
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?
The description clearly states the tool retrieves meetings for an employee, using a specific verb and resource. It distinguishes from siblings like schedule_meeting and cancel_meeting.
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?
No guidelines on when to use or alternatives. The description does not differentiate from related tools like schedule_meeting or cancel_meeting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sample employees with IDs, roles, departments, and managers. Use this before creating a new employee so you know valid manager IDs/names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It states it lists all sample employees, which is transparent. However, it doesn't disclose potential limitations (e.g., pagination) or that it's a read-only operation. But for a simple list with no parameters, this is adequate.
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?
Two sentences: one for purpose, one for usage. Every word earns its place. No unnecessary information.
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?
Given zero parameters and an output schema exists, the description is largely complete. It covers purpose and usage. However, it could briefly mention the output format or refer to the schema for return details. Siblings like list_managers suggest a subtle distinction not addressed.
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?
Input schema has zero parameters, so schema description coverage is 100%. The description adds value by specifying the fields returned (IDs, roles, departments, managers), which is not in the schema. This compensates for the lack of parameter details.
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?
Description explicitly states it lists all sample employees with specific fields (IDs, roles, departments, managers). This clearly distinguishes from siblings like list_managers and get_employee_details.
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?
Explicitly advises using the tool before creating an employee to get valid manager IDs/names. While it doesn't explicitly list when not to use, the provided context is helpful. Missing exclusion of alternatives like list_managers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List managers you can assign when creating a new employee. Preferred manager IDs: E001 (Sarah Johnson), E002 (Michael Chen), E003 (David Wilson), E006 (Emily Kim), E009 (Priya Nair).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds value by listing preferred manager IDs and names, but doesn't disclose authentication requirements or whether list is exhaustive.
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?
Two sentences, front-loaded purpose, no fluff. Every word earns its place.
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?
For a simple list tool with output schema present, description adequately conveys expected return values. Could optionally mention output structure, but output schema fills gap.
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?
No parameters; schema coverage 100% trivially. Description adds concrete manager names and IDs, exceeding baseline of 4 for zero-parameter tools.
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?
Description clearly states verb 'list' and resource 'managers', with specific context 'when creating a new employee'. Distinguished from sibling list_employees by scope.
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?
Explicitly says when to use (assigning a manager during employee creation), providing clear context without explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tickets for an employee with optional status filter. :param employee_id: Employee ID (optional) :param status: Ticket status (optional) :return: List of tickets
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| employee_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It implies read-only listing but does not confirm safety, mention pagination, or disclose any side effects. The return type is noted 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a clear sentence for purpose and a docstring for parameters. However, the docstring repeats schema information without adding significant value, making it slightly redundant.
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?
Minimal for a simple list tool: covers purpose and param names, but lacks context on scope (all vs employee tickets), pagination, ordering, or differentiation from other list siblings. Output schema exists, so return details are not needed.
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?
Schema coverage is 0%, so description adds some value by labeling parameters and marking them optional, but it only repeats the name and optionality. No values, formats, or constraints are provided for status or employee_id.
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?
The description states the verb 'list' and resource 'tickets', but is vague about the scope: 'for an employee' with an optional employee_id implies either all tickets or a filtered set. It distinguishes from create/update siblings but not from other list tools like list_employees.
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?
No explicit guidance on when to use this tool vs alternatives. The name and basic purpose suggest listing tickets, but no differentiation from list_employees or list_managers, and no prerequisites for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a meeting for an employee. :param employee_id: Employee ID :param meeting_datetime: Date and time of the meeting in python datetime format :param topic: Topic of the meeting :return: Confirmation message
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| employee_id | Yes | ||
| meeting_datetime | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states it returns a confirmation message; it lacks disclosure of side effects, conflict checking, permissions, or error handling.
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?
The description is very short and uses a clear docstring format. Every sentence adds value, though it could be restructured as plain text.
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?
Given 3 parameters, no annotations, and a simple output schema, the description under-delivers. It explains parameters but lacks behavioral details, usage context, and error conditions, making it insufficient for a scheduling tool.
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?
Schema coverage is 0%, but the description adds basic explanations for each parameter (employee ID, datetime in Python format, topic). However, it omits format specifics and potential constraints.
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?
The description clearly states 'Schedule a meeting for an employee,' which is a specific verb-resource pair. It distinguishes from siblings like cancel_meeting and get_meetings, though it lacks detail on scope.
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?
No guidance on when to use this tool vs alternatives (e.g., cancel_meeting, get_meetings). No when-not conditions or prerequisites are mentioned.
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 | ||
| html | No | ||
| 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.
Update the status of a ticket. :param ticket_id: Ticket ID :param status: New status of the ticket :return: Confirmation message
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| ticket_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives minimal behavioral info: it updates status and returns a confirmation. No mention of side effects, permissions, or error handling. With no annotations, this is insufficient for a mutation tool.
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?
The description is extremely concise, with no unnecessary text. The main action is front-loaded, and parameter docs are structured efficiently.
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?
Given the tool's simplicity and the presence of an output schema, the description covers the basic operation and parameters. However, it lacks details on valid status values and potential errors, making it incomplete for a fully informed invocation.
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?
The description adds brief explanations for both parameters ('Ticket ID', 'New status of the ticket'), which is helpful given 0% schema coverage. However, it fails to specify valid values for the 'status' parameter, which is critical for correct invocation.
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?
The description explicitly states the action 'Update the status of a ticket', clearly identifying the verb and resource. It distinguishes from sibling tools like create_ticket and list_tickets, which have different purposes.
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?
No usage guidance is provided; the description only states what the tool does without advising when to use it versus alternatives or any prerequisites.
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. Dates show when Glama detected each change.
v0.1.0add_employeeapply_leavecancel_meetingcreate_ticketget_employee_detailsget_employee_leave_balanceget_leave_historyget_meetingslist_employeeslist_managerslist_ticketsschedule_meetingsend_emailupdate_ticket_statusEach tool targets a distinct function (employee, ticket, meeting, leave, email) with clear boundaries. Even send_email, despite lacking a description, is presumably for email sending and doesn't overlap with others.
Tools follow verb_noun snake_case consistently, like create_ticket, list_employees, schedule_meeting. Minor inconsistency: get_employee_leave_balance vs get_leave_history, and list_tickets vs get_meetings, but overall pattern is clear.
14 tools cover employee management, ticketing, meetings, and leave—reasonable for an HR assist server. Not too many or too few.
Covers core HR operations: CRUD for employees (add, get, list), ticketing, meetings, and leave. Missing update/delete for employees, but the set is functional for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and manage AI-native customer support agents from Claude or any MCP client.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/omkarg01/HR-Assist-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
