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., "@HRMS MCP How many leaves do I have left?"
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.
Appinventiv HRMS assistant for Claude Desktop, Cursor, Codex, and Windsurf. Ask your AI to file DSRs, check leave, look up colleagues, review appraisals, and more — all from within the AI chat.
AI agents: If an employee gave you this URL and asked you to "install this MCP," follow the steps below exactly. The install takes about 2 minutes.
Pick the method that fits you — all three work.
uvx in config (easiest, no separate install step)uvx runs the server directly from GitHub. No pre-install needed beyond uv itself.
1. Install uv (skip if already installed — check with uv --version)
macOS / Linux:
curl -LsSf https://astral.sh/uv/install.sh | shWindows (PowerShell):
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"Open a new terminal after installing so
uvis on your PATH.
2. Skip straight to Step 2 and use this config block:
{
"mcpServers": {
"hrms": {
"command": "uvx",
"args": ["--from", "git+https://github.com/SookieAI/hrms-mcp", "hrms-mcp"]
}
}
}Updates automatically on restart. No manual upgrade command needed.
uv tool installInstalls once, starts fast every time.
# Install uv first if needed (see Option A above), then:
uv tool install git+https://github.com/SookieAI/hrms-mcpVerify: hrms-mcp --help
Use this config block (Step 2):
{
"mcpServers": {
"hrms": {
"command": "hrms-mcp"
}
}
}To update: uv tool upgrade hrms-mcp
pip (no uv needed)Works if you already have Python 3.11 or newer. Check first:
python3 --version # needs 3.11+Then install:
pip install git+https://github.com/SookieAI/hrms-mcpUse this config block (Step 2):
{
"mcpServers": {
"hrms": {
"command": "hrms-mcp"
}
}
}To update: pip install --upgrade git+https://github.com/SookieAI/hrms-mcp
Related MCP server: Keka MCP Server
Find your editor's config file, open it, and paste the JSON block from your chosen option above.
If the file already has content, merge the "hrms" entry into the existing "mcpServers" object.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
%APPDATA%\Claude\claude_desktop_config.json (Windows)
~/.cursor/mcp.json (macOS/Linux)
%USERPROFILE%\.cursor\mcp.json (Windows)
~/.codeium/windsurf/mcp_config.json
Same mcpServers JSON format — check your client's docs for the config file location.
Open Chrome → go to https://dashboard.appinventiv.com and sign in
Open DevTools (F12) → Network tab → click any request → copy the full Cookie: header value
Restart your AI editor, then tell your AI: "Login to HRMS" and paste the cookie when it asks
The cookie is saved to ~/.config/hrms-mcp/cookies and reloaded automatically on every restart.
You won't need to do this again until your HRMS session expires (usually a few weeks).
Ask your AI... | What happens |
"File my DSR for today — 4h on YourAI, [description]" | Submits DSR to HRMS |
"What did I file for DSR last week?" | Shows your submitted DSRs |
"How many leaves do I have left?" | Shows leave balance |
"Apply for leave from June 25 to 27" | Submits leave request |
"Who is Anish Katoch? What team is he on?" | Staff directory lookup |
"Show me open job positions in Design" | Lists current openings |
"What's the status of my appraisal?" | Appraisal status and sections |
"Who do I need to rate for appraisal?" | Lists employees pending your rating |
"Show me the interview pipeline" | Lists scheduled interviews |
"What projects am I on?" | Your active projects + hours |
"Morning check" | DSR status, leave balance, interviews, appraisals at once |
uv: command not found after installing
Open a new terminal window — uv updates your PATH only for new sessions.
On Windows, restart PowerShell. Still missing? Add ~/.local/bin (Mac/Linux) or %USERPROFILE%\.local\bin (Windows) to your PATH.
hrms-mcp: command not found
Open a new terminal after installing. If still missing, re-run the install command from your chosen option above.
"Not logged in" error
Your HRMS session expired. Go to dashboard.appinventiv.com, copy a fresh Cookie header from DevTools, and tell your AI "Login to HRMS" again.
Server not showing up in Claude / Cursor Restart the editor completely (quit and reopen — not just reload window). MCP servers load at startup only.
Python version error during pip install
pip install requires Python 3.11+. Run python3 --version to check. If older, use Option A or B (uv handles the Python version automatically).
Check which version is running Ask your AI: "check login status" — the response includes the version number and update command.
git clone https://github.com/SookieAI/hrms-mcp
cd hrms-mcp
uv run python server.py # run server
uv run python -c "from server import get_projects; print(get_projects())" # test a toolSee CLAUDE.md for architecture notes, DataTables AJAX patterns, CSRF handling, and how to add new tools.
# 1. bump version in pyproject.toml and server.py (__version__)
# 2. commit, tag, push to both remotes
git add -A
git commit -m "vX.Y.Z — description"
git tag vX.Y.Z
git push origin main --tags # GitLab (CI runs here)
git push github main --tags # GitHub (employees install from here)Submit a leave application to HRMS for manager approval. Always call get_leave_balance() first to confirm sufficient balance exists for the requested type. Confirm dates and leave type with the user before submitting — leave applications cannot be cancelled from the MCP. Returns success with leave type and date range, or an error if the form submission fails.
| Name | Required | Description | Default |
|---|---|---|---|
| leave_type | Yes | Leave type exactly as shown in HRMS. Options: 'Planned Leave (CL)', 'Privileged Leave', 'Emergency Leave', 'Short Leaves', 'Work From Home (WFH)'. | |
| from_date | Yes | Leave start date in YYYY-MM-DD format. Example: '2026-06-25'. | |
| to_date | Yes | Leave end date in YYYY-MM-DD format. Same as from_date for single-day leave. Example: '2026-06-27'. | |
| reason | Yes | Reason for the leave request. Be specific. Example: 'Travelling for a family event out of town'. | |
| half_day | No | Whether this is a half-day leave. Use '1' for half day, '0' for full day. | 0 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: submission is irreversible ('cannot be cancelled'), returns success/error, and requires prior balance check. No contradictions.
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 at four sentences, each serving a distinct purpose: purpose, precondition, caution, and return info. Well-structured 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?
Given the presence of an output schema and complete schema coverage, the description adds necessary context: preconditions, user confirmation, cancellation warning, and return value. No gaps remain.
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 100%, so parameters are already well-documented. The description does not add parameter details beyond schema, but reinforces the need to confirm dates and type with the user. Baseline score of 3 is appropriate.
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 action and target: 'Submit a leave application to HRMS for manager approval.' It distinguishes itself from read-only sibling tools like get_leave_balance and get_my_leaves by focusing on submission.
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 explicit usage guidance: call get_leave_balance() first, confirm dates and leave type with user, and warns that leave applications cannot be cancelled. This covers when to use and important preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the HRMS session is authenticated and ready to use. Returns logged_in status, where the cookie came from (file vs env), and the running version. Always call this first if other tools return 'Not logged in' errors. Also shows the update command if a newer version of hrms-mcp is available via uv tool upgrade.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes it as a read-only operation returning status, cookie source, version, and update command. No annotations to contradict. Could mention if it has side effects, but likely none.
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?
Three concise sentences, front-loaded with main purpose. Every sentence adds value, zero waste.
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?
Description covers return fields sufficiently (logged_in, cookie source, version, update command). Given low complexity and no parameters, it is fully informative.
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%. Description adds meaning by explaining return values, which is appropriate for a parameterless tool. Baseline 4 applies.
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 it checks if HRMS session is authenticated, identifies verb and resource. Distinguishes from sibling tools like login by being a status check.
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 to call first if other tools return 'Not logged in' errors. Provides strong guidance on when to use, though lacks explicit when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the list of employees you need to rate as part of the current appraisal cycle (PM/Manager view). Returns each employee's name, department, experience, shared projects, request date, and rating status. Status values: 'PENDING' means you haven't rated them yet, 'N/A' means not applicable. Use this to check who still needs your rating before the appraisal deadline.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately conveys that this is a read-only operation (starts with 'View') and explains the meaning of status values. It does not reveal any potential side effects, but the nature of the tool is simple and non-destructive.
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 with four informative sentences, each serving a distinct purpose: stating the action, listing output, explaining status, and providing usage context. No redundant or verbose elements.
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 (no parameters, has output schema), the description covers essential aspects: purpose, output fields, status meanings, and usage hint. It could mention that it's a read operation or require manager role, but these are implied.
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 input schema has zero parameters, so no parameter descriptions are needed. The baseline for 0 parameters is 4, and the description adds value by detailing the output fields and status values, which are relevant to the tool's behavior.
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: viewing employees needing ratings in the current appraisal cycle. It uses a specific verb ('View') and identifies the target user ('PM/Manager view'). It distinguishes itself from sibling tools like 'get_my_appraisal' by focusing on rating others.
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 clear guidance on when to use the tool: to check who still needs rating before the deadline. While it doesn't explicitly state when not to use it, the context and alternative sibling tools make it sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an Appinventiv employee's profile by name — returns their role, department, email, and employee_id. If multiple employees match, all are returned. Use the employee_id with get_employee_dsrs() to see their DSR history. Prefer this over get_staff_directory() when you want a single employee's full details. Example: get_employee_details('Arjun Sharma') → {name, role, department, email, employee_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| name_query | Yes | Part of the employee's name to search for (case-insensitive). Example: 'Anish Katoch' or just 'Anish'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that multiple employees may match and all are returned. Implies read-only operation through 'look up'. Does not mention failure scenarios, but adequate for a lookup 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?
Three sentences plus an example, front-loaded with core purpose. Every sentence is informative and efficient, no wasted words.
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 (one parameter, output schema exists), the description is complete: covers purpose, usage, example, and return fields. No gaps.
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?
Only one parameter with 100% schema coverage. Description adds value by providing an example and clarifying case-insensitivity, which is already in schema but reinforced.
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 looks up an employee's profile by name and lists the returned fields. It also distinguishes from a sibling tool, get_staff_directory, by specifying preference for single 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 states when to use (single employee full details) and when to prefer get_staff_directory. Provides a use case and example, and advises to use the employee_id with get_employee_dsrs for DSR history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full DSR content (project, hours, description) for any employee by their ID. Use get_employee_details(name) first to find the numeric employee_id from the staff directory. For your own DSRs, use employee_id='4907'. Returns project name, hours logged, and description text per day. Useful for reviewing what you or a team member worked on before writing a status report.
| Name | Required | Description | Default |
|---|---|---|---|
| employee_id | Yes | Numeric employee ID. Your own ID is 4907. Find others via get_employee_details(). Example: '4907'. | |
| date | No | Optional date filter in YYYY-MM-DD format to see DSRs for a single day. Leave empty for full history. Example: '2026-06-16'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the returned fields (project, hours, description per day) and that date is optional, but does not mention access restrictions, rate limits, or any behavioral 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?
Three concise sentences front-load the core purpose and function. No redundant or vague wording; every sentence adds value.
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?
With an output schema present, the description adequately covers what the tool returns and usage flow. Could be improved by mentioning the sibling get_my_dsrs for personal DSRs to avoid confusion.
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 100% with detailed parameter descriptions. The description adds meaningful context: employee_id is numeric, own ID is 4907, and date expects YYYY-MM-DD format with empty for full history. This goes beyond the schema's default descriptions.
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 it retrieves full DSR content (project, hours, description) for any employee by ID. It distinguishes from siblings like get_my_dsrs by indicating that it can be used for any employee, including oneself via employee_id='4907'.
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?
Provides explicit guidance: use get_employee_details first to find the numeric ID, and for own DSRs use employee_id='4907'. Mentions usefulness for status report preparation. However, does not explicitly advise against using this if get_my_dsrs is available for personal DSRs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the company holiday calendar for the current year. Note: The HRMS holiday calendar is a static PNG image — no individual holiday list is available. Returns the direct URL to the calendar image (e.g. /uploads/calendar/2026.png) which the user can open. If you need to answer questions like 'is June 25 a holiday?', ask the user to open the image URL returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the tool's behavior: it returns a URL to a static PNG image. It clearly states what the tool does not do (provide an individual holiday list), ensuring transparency despite the absence of annotations.
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, consisting of three sentences that efficiently convey purpose, limitation, and usage advice. There is no redundant information, and each sentence adds value.
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 is complete for this simple tool. It explains the output format (URL to PNG) and provides an example. Since an output schema exists, the description does not need to detail return values further. It also offers practical guidance for follow-up questions.
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 tool has no parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter information. According to guidelines, a baseline of 4 is appropriate for tools with zero parameters.
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: to view the company holiday calendar for the current year. It specifies the output is a URL to a PNG image, which distinguishes it from sibling tools like get_my_leaves or apply_leave.
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 explicit guidance on when to use the tool and its limitations. It notes that the calendar is a static image with no individual holiday list, and advises that for specific holiday queries, the user should open the returned image URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the list of interview candidates assigned to you as interviewer. Returns each candidate's name, email, mobile, interview round type, scheduled date/time, business unit, and final status (e.g. Selected, Rejected, Pending). Use this before interviews to prepare, or after to check which candidates are still pending a decision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states 'View the list,' implying a read-only operation, which is good. However, it does not explicitly confirm the operation is safe/destructive-free or discuss authorization requirements or rate limits.
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: first sentence states purpose, second lists return fields, third provides usage context. Every sentence adds value, with no wasted words.
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 has zero parameters and an output schema (as indicated by context signals), the description is complete. It explains the return fields and provides use cases, making it fully informative for an agent to select and invoke the 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?
The tool has zero parameters, so baseline is 4. The description does not need to add parameter meaning beyond the schema, which is fully covered.
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: 'View the list of interview candidates assigned to you as interviewer.' It specifies the resource (interview candidates) and action (view), and lists the returned fields, distinguishing it from sibling tools like get_employee_details or get_projects.
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 explicit usage context: 'Use this before interviews to prepare, or after to check which candidates are still pending a decision.' This clearly indicates when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View current open job positions at Appinventiv for referrals or internal hiring visibility. Returns job code (#APxxxx), title, number of openings, hired count, experience requirement, and location. Optionally filter by department keyword. Use get_my_referrals() to see candidates you've already referred.
| Name | Required | Description | Default |
|---|---|---|---|
| department | No | Filter by department name (partial match, case-insensitive). Examples: 'React JS', 'Data Science', 'Project Management', 'Design'. Leave empty for all open positions. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes what data is returned without disclosing authentication needs, rate limits, or side effects. It implies read-only behavior but does not state it explicitly.
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 three sentences long: first sentence states purpose, second lists return fields, third covers optional filter and alternative tool. No redundant information; front-loaded with purpose.
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 optional parameter and an existing output schema, the description covers the purpose, return data, filter option, and points to a related sibling tool. No gaps are apparent.
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 100% with a well-described 'department' parameter including default value and examples. The description adds minimal additional insight beyond what the schema provides, so baseline 3 is appropriate.
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 verb ('View'), resource ('current open job positions'), and context ('for referrals or internal hiring visibility'). It lists the return fields, distinguishing it from sibling tools like get_my_referrals.
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 explicitly says when to use the tool and provides an alternative for a related task ('Use get_my_referrals() to see candidates you've already referred'). It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your current leave balance showing remaining days for each leave type. Returns a dict like {"Planned Leave (CL)": "8 / 12", "Privileged Leave (PL)": "15 / 15"}. Call this before apply_leave() to confirm you have enough balance. Leave types: Planned Leave (CL), Privileged Leave (PL), Emergency Leave, Short Leaves, Work From Home (WFH).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format and lists leave types, but does not mention behavioral traits like read-only nature, authentication requirements, or potential errors. The simplicity of the tool mitigates the gap, but more transparency would be beneficial.
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: first sentence states purpose, then example, usage guidance, and list of leave types. Every sentence adds value, and there is no fluff.
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 the main purpose, return format, and a use case. However, it lacks information about prerequisites (e.g., authentication), error handling, or edge cases. Given the tool's simplicity and the presence of an output schema, the description is mostly complete but could be improved.
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 tool has no parameters, so the baseline is 4. The description adds value by explaining the output format and providing an example, which is helpful beyond the schema.
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 purpose clearly: 'Check your current leave balance showing remaining days for each leave type.' It provides a specific verb and resource, and includes an example return format. However, it does not explicitly differentiate from sibling tools like get_my_leaves, which could lead to confusion.
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 explicitly advises calling this tool before apply_leave() to confirm balance, providing a clear usage context. It does not mention when not to use or alternatives, but the guidance is direct and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your own appraisal status for the current appraisal cycle. Returns the appraisal period (e.g. 'January – June 2026'), submission status (Submitted/Pending), and which sections are covered (Project Accomplishments, Competencies, 6-Month Plan, etc.). Use get_appraisal_ratings() if you are a PM and need to rate your team members.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses that this is a read-only operation returning specific data fields (period, status, sections). No side effects or permissions issues are relevant, and the description is honest about what it does.
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 two sentences long, front-loaded with the main purpose, and every word contributes value. No fluff.
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 tool with no parameters and an output schema, the description explains exactly what is returned. It is fully adequate for an agent to understand its behavior.
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 exist, and schema description coverage is 100%. The description adds no param info but none is needed; baseline 4 is appropriate.
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 verb 'View' and the resource 'your own appraisal status for the current appraisal cycle'. It distinguishes from the sibling tool 'get_appraisal_ratings' which is for PMs to rate team members.
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 explicitly says when to use this tool (view own appraisal) and when not ('Use get_appraisal_ratings() if you are a PM...'), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your personal DSR filing status — which days are Submitted, Pending, or missing. Returns up to 200 rows with date, check-in time, and DSR_Status per day. Use this to check if you missed filing DSRs on specific days, or to review last week's submissions. Does NOT return the DSR description text — use get_employee_dsrs(employee_id) for that.
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | No | Filter start date in YYYY-MM-DD format. Leave empty to get last 30 days. Example: '2026-06-01'. | |
| date_to | No | Filter end date in YYYY-MM-DD format. Leave empty for today. Example: '2026-06-17'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. Discloses output limit (200 rows), returned fields, and exclusion of description text. Could add auth requirements but overall transparent.
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?
Three concise sentences: purpose first, then output details, then usage guidance and limitation. No wasted words.
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?
Output schema exists so return values need not be detailed; description already mentions key fields. For a tool with 2 optional params and a clear scope, everything needed is present.
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?
100% schema coverage means baseline 3. Description adds context about default behavior when left empty and examples, reinforcing schema meaning.
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?
Clear verb 'View' and resource 'personal DSR filing status', distinguishes from sibling get_employee_dsrs by explicitly stating what it does not return and pointing to the alternative.
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?
Provides explicit use cases (check missed filings, review submissions) and clearly notes what is not returned, directing to an alternative tool. Lacks explicit when-not-to-use but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all leave applications you have submitted with their approval status. Returns leave type, from/to dates, number of days, and status (Approved/Pending/Rejected). Use this to check if a leave was approved or to see your leave history. For current leave balances (days remaining), use get_leave_balance() instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries the burden. It describes the read operation and lists returned data. However, it does not explicitly state that it is non-destructive or mention any auth requirements. Overall, adequate but could be more explicit about safety.
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?
Three sentences, each adding value: purpose, return fields, usage guidance. No wasted words. Front-loaded with purpose.
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 tool with no parameters and an output schema, the description covers purpose, usage, and return fields. It also provides alternative tool. No gaps.
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 baseline is 4. Description adds no parameter info, which is appropriate.
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 'View all leave applications you have submitted with their approval status.' Provides specific verb and resource, and lists return fields. Distinguishes from sibling get_leave_balance by focusing on history vs. balances.
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 'Use this to check if a leave was approved or to see your leave history.' Also gives alternative: 'For current leave balances (days remaining), use get_leave_balance() instead.' Provides clear when-to-use and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all projects you are allocated to, with status and total DSR hours logged since Jan 2024. Returns project name, allocation (hours/day), status (Active/Released), and cumulative logged hours. Use this for a high-level view of your project allocation. For detailed DSR entries, use get_employee_dsrs().
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields and a time boundary (since Jan 2024), but does not mention side effects, authentication needs, or edge cases (e.g., empty results). Adequate but could be more comprehensive.
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?
Three sentences, each earning its place: purpose, return fields, usage guidance. No wasted words, 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?
Given zero parameters and presence of output schema, description sufficiently covers what the tool returns and when to use it. Could optionally mention sorting or pagination, but not needed for this simple 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?
No parameters exist, so description need not add parameter info. It does explain the output meaning, which is valuable. Baseline for zero parameters is 4.
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 'View' and resource 'projects you are allocated to', and lists specific fields returned (status, DSR hours). It distinguishes from sibling tools like 'get_projects' and 'get_employee_dsrs'.
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 states when to use this tool ('high-level view of your project allocation') and provides an alternative for detailed entries ('use get_employee_dsrs()').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View all candidates you have referred to Appinventiv and their current recruitment pipeline status. Returns candidate name, position referred for, referral date, and status (e.g. Shortlisted, Rejected, Hired). Use get_job_openings() to find open positions you can refer people for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It implies a read-only operation ('View') and lists returned fields, but does not explicitly state side-effect-free or permission requirements. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, return details, and related tool. No wasted words, well-structured.
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, the description covers all necessary information: what it does, what it returns, and a pointer to a sibling tool. Fully adequate.
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, so baseline is 4. Description adds value by listing returned fields, which aids understanding of the output.
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 verb 'View' and the resource 'candidates you have referred', with additional detail on pipeline status. It distinguishes from siblings as no other tool handles referrals.
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 context for when to use the tool (view your referrals) and explicitly mentions an alternative tool (get_job_openings) for finding open positions. It lacks explicit exclusions but offers clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the PM project dashboard for active projects — shows billing type, team size, total hours budgeted vs consumed, milestone count, and delivery progress percentage. This is the Project Manager view showing your active project health at a glance. For your personal project allocation list, use get_my_projects() instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes a read-only view ('View') and lists displayed data. No annotations exist, so description carries full burden; it is mostly transparent but could explicitly state it is read-only and has no 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?
Two sentences with no fluff; first sentence front-loads purpose and data shown, second provides alternative tool. Highly concise and well-structured.
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 parameters and has an output schema, so description doesn't need return value details. It fully covers purpose, data provided, and differentiation from sibling, making it complete for this simple 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?
Input schema is empty with 100% coverage; baseline for 0 parameters is 4. Description does not need to add parameter info and correctly omits it.
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 tool views the PM project dashboard for active projects, listing specific metrics. It distinguishes from sibling get_my_projects by noting it is the Project Manager view, not the personal allocation list.
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 (view dashboard for active projects) and when not (for personal allocation, use get_my_projects instead), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects you can log DSR hours against, pulled from the DSR form dropdown. Returns each project's numeric ID and display name. Use the ID with submit_dsr(). Example return: [{"id": "1005", "name": "YourAI LLC"}, {"id": "890", "name": "Flynas"}]. Call this before submit_dsr() if you don't know the project_id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (numeric ID and display name), provides an example, and mentions using ID with submit_dsr(). With no annotations, this adequately describes behavior for a read-only listing 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?
Concise four-sentence description with front-loaded purpose. Every sentence adds value: purpose, return format, example, usage hint.
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?
Fully covers purpose, usage, and return format. Output schema exists, so detailed return description isn't needed. Appropriate for a simple zero-parameter 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?
No parameters, so schema coverage is 100%. Baseline 4 applies. Description adds value by explaining output format and usage beyond the empty schema.
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 lists projects for logging DSR hours, pulled from a specific dropdown. It distinguishes from siblings like get_my_projects by specifying the scope (all projects you can log DSR hours against).
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 to call before submit_dsr() if you don't know the project_id. Provides clear context for when to use, though it doesn't mention when not to use or alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Appinventiv's staff directory of 1,237 employees by name. Returns matching employees with name, role, department, email, and employee_id. The employee_id is needed for get_employee_dsrs(). For full profile lookup, use get_employee_details() instead. Always search by name — browsing the full directory is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Name or partial name to search for. Case-insensitive. Leave empty to get the first ~20 employees alphabetically. Example: 'Anish' or 'Kalra'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses case-insensitive search, empty search returns ~20 alphabetically, and return fields. Missing info on pagination or max results, but overall transparent.
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?
Three sentences, no wasted words. First sentence states action and resource, second lists return fields, third provides usage constraints and related tools. Front-loaded with key purpose.
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?
Description covers all necessary aspects: purpose, usage, parameter behavior, related tools, and output fields. Given single optional parameter, existing output schema, and sibling tool context, it is fully 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?
Schema description coverage is 100% with detailed parameter info (default, case-insensitive, example). Description adds value by explaining the parameter's role in context (always search by name) and linking to other tools, justifying a score above baseline 3.
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 'Search', specific resource 'Appinventiv's staff directory', and scope 'by name'. Differentiates from sibling get_employee_details by noting it returns only basic fields and that full profile lookup requires a different tool.
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 instructs 'Always search by name — browsing the full directory is not supported.' Also states that employee_id is needed for get_employee_dsrs() and suggests get_employee_details() for full profile, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save your HRMS session cookie so all other tools work. Only needed once — the cookie persists across MCP restarts in ~/.config/hrms-mcp/cookies and is reloaded automatically. How to get: Chrome → dashboard.appinventiv.com → DevTools (F12) → Network tab → click any request → copy the full 'Cookie:' header value → paste here. Returns success/failure and whether the session is valid after saving.
| Name | Required | Description | Default |
|---|---|---|---|
| cookie | Yes | The full Cookie header string from Chrome DevTools. Example: 'ci_session=abc123; AWSALB=xyz; csrf_hrsale=tok'. Or just the ci_session value alone. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: saves cookie to ~/.config/hrms-mcp/cookies, persists automatically, and returns success/failure with session validity. No contradictions.
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?
Description is efficient with no wasted words. It front-loads the main purpose, then provides step-by-step instructions, and ends with return behavior. Each sentence 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?
Given the simplicity (single parameter, no nested objects) and presence of an output schema (which details return values), the description is complete. It explains the return format (success/failure and validity) adequately.
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 single parameter is fully described in the schema with 100% coverage. The description adds value beyond the schema by providing context on how to obtain the cookie (DevTools instructions) and an example value format, elevating it above baseline 3.
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 it saves the HRMS session cookie to enable all other tools, using the verb 'save' and specifying the resource 'HRMS session cookie'. It distinguishes itself from the sibling 'login_via_browser_capture' by describing manual cookie extraction via DevTools.
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 only needed once, cookie persists across MCP restarts, and provides step-by-step instructions on how to obtain the cookie. It implies when to use this tool (first-time setup) versus potentially automated alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a local web page where the user can paste their HRMS Cookie header via a browser form. IMPORTANT: Tell the user to open http://localhost:/ in Chrome BEFORE calling this tool — the tool blocks until the cookie is submitted (up to timeout_seconds). The port is dynamic; if it times out the error message includes the URL. Prefer login() for a simpler flow. Returns success once the cookie is captured and verified against HRMS.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_seconds | No | Seconds to wait for the user to paste the cookie in the browser. Default 180 (3 min). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses blocking behavior, timeout, and return on success. No annotations provided, so description carries full burden. Lacks details on post-success behavior (e.g., session management) but adequate given simplicity.
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 paragraphs, front-loaded with core action, followed by essential usage notes. No superfluous 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?
Complete for a simple tool: describes action, prerequisite, blocking behavior, timeout, alternative, and return value. Output schema exists, but description's mention of return is sufficient.
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 has 100% coverage for the single parameter, but description adds context on blocking behavior and timeout, enhancing understanding beyond schema.
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 opens a local web page for cookie capture and distinguishes itself from the simpler 'login' sibling. The verb 'opens' and resource 'local web page' are specific.
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 instructs the user to open the URL before calling the tool, explains blocking behavior, timeout, and prefers the 'login' alternative for simpler flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a Daily Status Report (DSR) for a specific project and date. Always call get_projects() first to get the correct project_id if you don't have it. One DSR per project per day — submitting again for the same project+date will update it. Returns success with the date, hours, and project_id on success, or an error with recovery guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Numeric project ID from get_projects(). Example: '1005' for YourAI LLC, '890' for Flynas. | |
| date | Yes | Date to log DSR for, in YYYY-MM-DD format. Example: '2026-06-17'. Must be today or a past date. | |
| hours | Yes | Hours worked on this project. Use decimals for half-hours. Example: 8 or 4.5. Must be between 0.5 and 24. | |
| description | Yes | What you worked on — tasks completed, progress made, blockers. At least 10 characters. Example: 'Reviewed AI module integration and fixed API timeout issue.' | |
| ai_tools_used | No | Whether you used AI tools (Claude, ChatGPT, Copilot, etc.) today. Use '1' for yes, '0' for no. | 0 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return format (success with date, hours, project_id; error with recovery guidance) and idempotent update behavior, fully compensating for absent annotations.
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?
Four sentences, front-loaded with core purpose, no redundant information, efficient and structured.
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?
Covers all aspects: purpose, prerequisites, update semantics, return values, and error handling; complemented by an output schema (not shown) and references to sibling tools.
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 covers 100% of parameters with detailed descriptions, examples, and constraints; the tool description adds context like the prerequisite get_projects call.
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 the tool submits a Daily Status Report for a specific project and date, distinguishing it from sibling tools like get_my_dsrs (retrieval) and apply_leave (different resource).
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 instructs to call get_projects() first for the project_id and explains the update behavior on duplicate submission, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but login_via_browser_capture and login are very similar, and check_login_status adds redundancy. Some tools like get_employee_details and get_staff_directory overlap in employee lookup, though descriptions clarify differences. Overall, minor ambiguity exists.
The naming follows a consistent verb_noun pattern (get_*, apply_*, submit_*, login). However, login_via_browser_capture is a long exception, and check_login_status uses a different verb. The pattern is mostly predictable with a few deviations.
20 tools cover HRMS domains comprehensively (leave, DSR, appraisal, staff, projects, interviews, referrals). This is slightly on the higher side but justified by the breadth of functionality. No tool seems redundant or missing for the intended scope.
The tool set covers key reading and some writing actions (leave apply, DSR submit) but lacks update/delete for most resources (e.g., no cancel leave, no delete DSR). Some CRUD gaps exist, but the descriptions indicate intentional limitations (e.g., leave cannot be cancelled). Partial completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI hiring tools CV screening, social media profile scan, and document search for any organization.
AI screening interviews, resume matching, and evidence-linked scorecards for recruiting teams.
Manage projects, tasks, time tracking, and team collaboration through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SookieAI/hrms-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
