keka-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP port when TRANSPORT=http | 3000 |
| TRANSPORT | No | stdio (default) or http | stdio |
| KEKA_API_KEY | Yes | API key from Keka admin | |
| KEKA_SANDBOX | No | Set to true to use kekademo.com sandbox auth | |
| KEKA_BASE_URL | Yes | Your Keka tenant URL, e.g. https://yourcompany.keka.com | |
| KEKA_CLIENT_ID | Yes | OAuth2 Client ID from Keka admin | |
| KEKA_EMPLOYEE_ID | No | Your own Keka employee ID — used as requestedBy when applying leave on behalf of others | |
| KEKA_CLIENT_SECRET | Yes | OAuth2 Client Secret |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| keka_list_employeesA | Retrieve a paginated list of employees from Keka HRM. Supports filtering by employment status, employee IDs, probation status, notice period, and a free-text search key. Args:
Returns: Paginated list of employees with ID, name, email, department, job title, status, and join date. Examples:
|
| keka_get_employeeA | Retrieve full details for a single employee by their Keka employee ID. Args:
Returns: Complete employee profile including personal info, department, job title, manager, location, and employment details. |
| keka_list_departmentsA | Retrieve all departments defined in Keka HRM. Args:
Returns: List of departments with IDs, names, parent department, and department lead. |
| keka_list_job_titlesA | Retrieve all job titles configured in Keka HRM. Args:
Returns: List of job titles with their IDs and names. |
| keka_list_groupsA | Retrieve all groups (teams/divisions) configured in Keka HRM. Args:
Returns: List of groups with IDs, names, and types. |
| keka_list_leave_typesA | Retrieve all leave types configured in Keka (e.g., Annual Leave, Sick Leave, Casual Leave). Args:
Returns: List of leave types with ID, name, code, and whether they are paid leave. Use the returned IDs when creating leave requests with keka_create_leave_request. |
| keka_list_leave_requestsA | Retrieve leave requests from Keka with optional filters for employees and date range. Args:
Returns: List of leave requests with employee, leave type, dates, number of days, status, and reason. Examples:
|
| keka_create_leave_requestA | Submit a new leave request for an employee in Keka. Args:
Returns: Confirmation of leave request creation with the generated request ID. Note: Requires the API key to have leave management write permissions. |
| keka_get_leave_balancesA | Retrieve leave balances for employees in Keka. Args:
Returns: Leave balance breakdown per employee and leave type — opening, earned, taken, pending, and closing balances. |
| keka_get_attendanceA | Retrieve attendance records for employees from Keka. The Keka API supports a maximum date range of 90 days per request and defaults to the last 30 days. Args:
Returns: Attendance records per employee per day — clock-in, clock-out, total hours, shift, and status (Present, Absent, Half-Day, etc.). Examples:
|
| keka_list_pay_groupsA | Retrieve all payroll groups configured in Keka. Pay groups define payroll cycles and are used to filter salary listings. Args:
Returns: List of pay groups with IDs, names, and descriptions. Use IDs with keka_list_salaries to filter by pay group. |
| keka_list_pay_bandsA | Retrieve all salary pay bands configured in Keka. Pay bands define compensation ranges for job levels or grades. Args:
Returns: Pay bands with ID, name, minimum and maximum salary amounts, and currency. |
| keka_list_salariesA | Retrieve salary information for employees from Keka payroll. ⚠️ This tool returns sensitive compensation data. Ensure your API key has payroll read access. Args:
Returns: Employee salaries with CTC (Cost to Company), pay group, currency, and effective date. |
| keka_list_jobsA | Retrieve all job openings from Keka Hire (Recruitment module). Args:
Returns: Job openings with ID, title, department, location, status, number of openings, posted date, closing date, and hiring manager. Use keka_list_candidates to see candidates for a specific job. |
| keka_list_candidatesA | Retrieve candidates for a specific job opening in Keka Hire. Args:
Returns: Candidate list with name, email, phone, current interview stage, application date, source, and status. |
| keka_list_psa_clientsA | Retrieve all clients from Keka's Professional Services Automation (PSA) module. Args:
Returns: PSA client records with ID, name, email, phone, status, and creation date. Use returned IDs with keka_list_psa_projects to find projects for a client. |
| keka_list_psa_projectsA | Retrieve projects from Keka's Professional Services Automation (PSA) module. Args:
Returns: PSA projects with ID, name, client, status, start/end dates, budget, currency, and project manager. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| apply_leave | Walks through the full leave application workflow: resolve employee, pick leave type, check balance, and submit. |
| check_leave_balance | Check leave balance for one or more employees. |
| who_is_on_leave | Check who is on leave for a given date range. |
| check_attendance | Check attendance records for employees. |
| find_employee | Look up employee info by name, email, or employee number. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Each tool targets a distinct entity and action—employees, leave types, requests, balances, attendance, salaries, jobs, candidates, PSA clients/projects—so no two tools overlap in purpose. Descriptions also cross-reference related tools, reinforcing correct selection.
All tools use the keka_ prefix with a consistent list/get/create verb followed by a clear noun, making behavior predictable. The naming pattern is uniform throughout the server.
At 17 tools, the count slightly exceeds the typical 3–15 range, but it is justified by the breadth of Keka modules covered (HR, payroll, leave, attendance, recruitment, PSA). There are no redundant tools, and each entity serves a clear purpose.
The set provides strong read coverage across multiple modules and supports creating leave requests, but it lacks update/delete/approval actions for most entities—such as employee updates, leave approvals, or candidate workflow steps. This leaves notable lifecycle gaps for a full HRIS integration.