hr-assist

by Jayeshm93

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions (employees, tickets, meetings, leave). However, send_email has no description and could be ambiguous, and get_employee_leave_balance vs get_leave_history might cause slight confusion despite being different.
Naming Consistency3/5
All names use snake_case with a verb_noun pattern, but there's inconsistency in verb choice (add, create, schedule, apply) and read operations (get vs list). The pattern is readable but not fully standardized.
Tool Count5/5
12 tools is well within the ideal range for an HR assistant server, covering employees, tickets, meetings, and leave without being excessive.
Completeness2/5
There are significant gaps: no employee update/delete, no ticket deletion or cancellation, no meeting update, no leave cancellation, and no employee list. The server covers create/read operations but lacks update/delete for most entities, which will hinder full lifecycle workflows.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only says 'Add a new employee' and mentions a confirmation message. It does not disclose side effects, permission requirements, validation rules, or what happens upon duplicate entries. This is minimal and insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. However, the inclusion of ':param' and ':return' lines in a non-standard format adds clutter and the parameter info is inaccurate. Still, it is appropriately sized and not verbose.
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 three required parameters, no annotations, and no output schema visible, the description is incomplete. It lacks the email parameter, misstates manager_id's optionality, and provides no context about side effects, validation, or return value format. The agent cannot fully understand the tool's behavior or requirements.
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?
Schema description coverage is 0%, so the description must explain parameters. It mentions emp_name and manager_id but omits email entirely. Worse, it labels manager_id as 'optional' while the input schema marks it as required. This direct contradiction and missing parameter would mislead an agent into incorrect invocations.
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 'Add a new employee to the hrms system', specifying the verb (add) and resource (employee in hrms). This is clear and unambiguous, but it does not explicitly distinguish from sibling tools like get_employee_details or apply_leave, though those are quite different in nature.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use. The description simply states the action, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions that a confirmation message is returned, but does not disclose side effects (e.g., whether participants are notified, whether the cancellation is permanent), permission requirements, or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence followed by parameter docstrings. It is front-loaded with the primary action and includes no fluff. The structure is readable and efficient, though the docstring style could be more integrated.
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?
An output schema exists, so return values don't need explanation. However, the description lacks context about prerequisites (e.g., meeting must exist), behavior when the meeting is not found, and the contradictory 'optional' topic flag introduces ambiguity. For a cancellation tool with no annotations, this is incomplete.
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?
The description adds some meaning to parameters (e.g., employee_id, meeting_datetime format, topic optional), which helps given the schema has 0% description coverage. However, it directly contradicts the schema by marking 'topic' as optional while the schema lists it as required. This misleading information undermines the value of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel a scheduled meeting') and the target resource ('an employee'), making it distinct from sibling tools like schedule_meeting and get_meetings. The verb+resource combination is specific and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., schedule_meeting, get_meetings). It lacks any explicit conditions, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a read operation ('get') but does not specify the scope of history (e.g., date range, statuses), any side effects, required permissions, or the exact return structure beyond a vague 'Leave history message.' No additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded in the first sentence. However, the ':return: Leave history message' line is vague and adds little value, making it somewhat less effective than it could be. Overall, it is not overly verbose and maintains a clear structure.
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?
The tool is simple, but the description lacks completeness by not explaining what 'leave history' includes or how it differs from the sibling tool get_employee_leave_balance. No behavior beyond the basic action is described, and the vague return statement does not help. Given no annotations and no output schema visible, more context is needed for a confident invocation.
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?
The schema has 0% coverage for parameter descriptions, so the description must compensate. The ':param emp_id: Employee ID' line provides a basic definition but adds little beyond the parameter name itself. It does not detail the format, constraints, or how emp_id relates to the leave history query, but for a single simple parameter, it is minimally sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the leave history of an employee' with a specific verb and resource, distinguishing it from sibling tools like get_employee_leave_balance (which focuses on balance) and apply_leave. The purpose is unambiguous and immediately understandable.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that leave history differs from leave balance, nor does it explain any context or exclusions. The agent is left to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states the action and return value ('Confirmation message') but does not mention permissions, side effects, error handling, or valid status transitions. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, with a clear one-sentence purpose statement and structured param docs. However, the param lines add little value beyond the schema, making some parts redundant.
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?
For a simple update operation, the description covers the basic action and return, but lacks critical context such as valid status values, potential errors, or prerequisites. The presence of an output schema does not compensate for the missing behavioral and usage guidance.
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%, so the description must compensate. The param lines ':param ticket_id: Ticket ID' and ':param status: New status of the ticket' are nearly tautological and provide no extra context about allowed values, formats, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update the status of a ticket,' which is a specific verb+resource phrase that clearly identifies the action. It distinguishes itself from sibling tools like create_ticket and list_tickets by focusing on status modification.
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?
There is no explicit guidance on when to use this tool or how it differs from alternatives. Usage is implied by the name and action, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It clearly indicates a read-only 'Get' operation and exposes the return fields. However, it lacks details on matching behavior (e.g., exact vs. partial name, case sensitivity) and error handling when an employee is not found, leaving important gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the main purpose. The param and return lines are clearly separated and add useful information without redundancy. It is slightly less polished than a purely declarative sentence but remains well-structured and free of filler.
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?
The tool is a simple lookup with one parameter and an output schema exists, so the description covers the essential request and response shape. However, it lacks usage guidance relative to sibling tools and does not address ambiguity or failure cases. Overall, it is minimally complete but has noticeable gaps.
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?
The schema has no description for the 'name' parameter (0% coverage), so the description's ':param name: Name of the employee' adds minimal meaning beyond the parameter name itself. It does not specify format, case sensitivity, or matching semantics, so it fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get employee details by name.' It also specifies the return values (Employee ID and manager ID), making the purpose unambiguous. This distinguishes it from the sibling tool get_employee_leave_balance, which focuses on leave 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?
The description provides no guidance on when to use this tool versus alternatives such as get_employee_leave_balance or list_tickets. It does not mention exclusions, prerequisites, or preferred use cases. The only implied usage is from the verb 'Get,' which is not sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns a 'leave balance message', which is vague and does not clarify side effects, error behavior, permission requirements, or whether the result is structured or plain text. The verb 'get' implies read-only, but the description does not explicitly confirm this or provide any additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It uses a single sentence to describe the action, followed by explicit :param and :return lines for the important contract points. There is no fluff, and the information is front-loaded in the opening sentence.
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?
The tool is simple, but the description has clear gaps: it does not explain when to use it over 'get_leave_history', does not describe the exact return format beyond 'message', and gives no behavioral details. Given the missing annotations and zero schema coverage, the description is minimally adequate but lacks the context needed for an agent to reliably distinguish and invoke this tool in all scenarios.
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 description coverage is 0%, so the description must compensate. The :param line clarifies that 'emp_id' stands for 'Employee ID', which adds slight meaning beyond the schema's property name and title. However, it does not specify the format or constraints for the ID, and it is nearly redundant with the parameter name. The compensation is minimal but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the leave balance of an employee.' It uses a specific verb ('get') and resource ('leave balance') and distinguishes from siblings like 'get_leave_history' which covers historical records, not current balance. The :param and :return lines further clarify the tool's purpose.
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?
There is no guidance on when to use this tool versus alternatives like 'get_leave_history' or 'apply_leave'. The description does not mention prerequisites, exclusions, or any preference for which sibling to choose. The only context is the name and a basic description, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral transparency burden. However, it only states the basic action and return type, without disclosing any behavioral traits such as whether cancelled meetings are excluded, ordering, pagination, or required permissions. This leaves the agent guessing about important operational details.
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 concise and front-loaded with the primary purpose in the first sentence. It follows a standard docstring style with ':param' and ':return' lines that are brief and conventional. There is no wasted content or unnecessary elaboration.
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?
The tool is straightforward with a single parameter and an output schema (not shown, but indicated), which reduces the need for descriptions of return values. However, the lack of usage guidelines and behavioral transparency makes the description only minimally adequate for reliable agent decision-making.
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?
The schema has a single parameter 'employee_id' with no description (coverage 0%). The description merely repeats the parameter name as 'Employee ID' without adding format, constraints, or examples. It does not meaningfully compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the list of meetings scheduled for an employee.' This uses a specific verb ('Get') and resource ('list of meetings') with a defined scope (per employee). It distinguishes itself from siblings like 'schedule_meeting' and 'cancel_meeting' by indicating it is a read-only retrieval operation.
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 usage by stating its purpose, but it does not explicitly say when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For example, there is no note about whether to use this for future meetings only or for historical ones, and no mention of alternatives like 'schedule_meeting'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions the return type ('List of tickets') but does not clarify side effects, permissions, privacy scoping, or behavior like pagination. The word 'list' implies read-only, but that's not explicit, and there's no mention of potential limitations or edge cases.
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 plus concise parameter documentation, with no filler. The main action is front-loaded and the parameter lines are clearly separated. This is appropriately sized for a simple tool.
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?
For a simple list operation with an output schema available, the description covers the essential inputs and return type. However, the discrepancy between 'optional status' and the required status in the schema creates ambiguity. Additional context about allowed status values or employee ID format would improve completeness, but the tool is not overly complex.
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?
The description provides parameter meanings (employee_id and status) which is helpful given 0% schema coverage. However, it contradicts the input schema by labeling status as optional while the schema marks both as required. This undermines the trust and clarity of the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'List tickets for an employee', which clearly identifies the tool's function. It is distinguished from sibling tools like create_ticket and update_ticket_status, and the scope ('for an employee') adds precision beyond just 'list tickets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an employee with optional status filter' conveys when to use the tool—when you need a list of an employee's tickets. However, it does not explicitly mention alternative tools or exclusions (e.g., 'use get_employee_details for other employee info'), so it lacks explicit when-not guidance but is clear enough for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a meeting is scheduled and a confirmation message is returned, but omits important details like conflict handling, validation of employee_id, timezone assumptions, or whether any notifications are sent. This could lead to misuse or unexpected 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by a compact parameter list and return note. No wasted sentences; every element serves a purpose.
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?
For a simple tool with 3 required string parameters, the description covers the basic parameters and return type, but lacks critical behavioral context such as meeting conflict resolution, employee validation, and timezone handling. The presence of an output schema partially covers return details, but the absence of annotations and behavioral clarifications leaves gaps.
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?
The description includes :param lines that explain each parameter, adding 'python datetime format' for meeting_datetime which is helpful. However, most explanations are redundant with property titles, and with 0% schema coverage, the description only partially compensates. It doesn't clarify constraints like required formats or uniqueness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Schedule a meeting for an employee' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'cancel_meeting', 'get_meetings', and 'apply_leave'. No ambiguity about the tool's primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement gives clear context that this tool is for creating meetings, and the sibling tools provide implicit alternatives (cancel, view, etc.). It doesn't explicitly mention when not to use it or name alternatives, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states the action and return value, without mentioning whether the operation checks leave balance, requires permissions, is reversible, or triggers notifications. For a mutation tool, this lacks necessary behavioral transparency.
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 extremely concise, front-loading the purpose in the first sentence and adding param documentation without any fluff. Every sentence earns its place, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema, the description covers purpose, parameters, and return value adequately. However, it lacks context about practical usage, such as prerequisites (e.g., sufficient leave balance) or side effects, but given the tool's simplicity and existing output schema, this is acceptable.
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?
The description provides :param lines for both parameters, adding semantics to the otherwise empty schema descriptions. 'Employee ID' and 'List of leave dates' clarify the parameters' meanings, though the format of dates (e.g., date range vs individual dates) is not specified. This partly compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply for leave for an employee' clearly, specifying the verb (apply) and resource (leave) with a target (employee). It is unambiguous and distinct from all sibling tools, including leave balance and history queries, which serve different purposes.
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?
Usage is implied from the purpose: this is the tool to apply for leave. However, no explicit guidance is given about when to use it versus checking leave balance first or any approval workflow. Alternatives are not mentioned, and no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions creating a ticket and returning a confirmation message, but does not disclose side effects, permissions, reversibility, or any other behavioral traits. For a mutation operation, this is a significant gap.
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 concise and front-loaded with the main purpose in the first sentence. The parameter documentation is clear and directly follows the purpose, with no unnecessary content. It efficiently conveys all essential information in four short statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ticket-creation tool, the description covers the primary purpose, all parameters, and the return type (confirmation message). It also provides examples for the item field. However, it lacks mention of prerequisites (e.g., employee must exist) or error conditions, but the simplicity of the tool makes these omissions minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its parameters (0% coverage), so the description must compensate. It does so thoroughly by providing meanings for all three parameters: emp_id (Employee ID), item (Item requested with examples), and reason (Reason for the request). This fully clarifies the required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a ticket for buying required items for an employee,' which uses a specific verb ('create') and resource ('ticket') with a clear purpose. This differentiates it from sibling tools like update_ticket_status and list_tickets, which handle other ticket operations.
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 the use case (creating a ticket for employee purchases) but does not explicitly state when to use this tool versus alternatives. There are no exclusions or comparisons with sibling tools like list_tickets or update_ticket_status, so the usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![HRMS-MCP MCP server](https://glama.ai/mcp/servers/Jayeshm93/HRMS-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Jayeshm93/HRMS-MCP)

Score Badge

Copy to your README.md:

[![HRMS-MCP MCP server](https://glama.ai/mcp/servers/Jayeshm93/HRMS-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Jayeshm93/HRMS-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Jayeshm93/HRMS-MCP'

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