keka-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KEKA_API_KEY | Yes | Keka API key from Global admin settings -> Integrations & Automations -> API access -> API key. | |
| KEKA_BASE_URL | Yes | Your company's data API host, e.g. https://yourcompany.keka.com | |
| KEKA_CLIENT_ID | Yes | Keka client ID from Global admin settings -> Integrations & Automations -> API access -> API key. | |
| KEKA_TOKEN_URL | Yes | Keka's OAuth login host, e.g. https://login.keka.com/connect/token for production or https://login.kekademo.com/connect/token for the demo/sandbox environment. | |
| KEKA_CLIENT_SECRET | Yes | Keka client secret from Global admin settings -> Integrations & Automations -> API access -> API key. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_timesheet_entriesA | Fetch PSA timesheet entries from Keka across employees/projects for a date range. Automatically pages through the entire result set and returns it combined - callers never need to loop on pageNumber themselves. The 'from'..'to' range cannot exceed 60 days (validated before calling Keka). Each entry's numeric |
| get_project_time_entriesA | Fetch PSA timesheet entries for a single project from Keka. Automatically pages through the entire result set and returns it combined. The 'from'..'to' range cannot exceed 60 days (validated before calling Keka). |
| get_employeesA | Fetch all employees from Keka HRIS. Automatically pages through the entire result set and returns it combined. Use this to map employee IDs found in timesheet data to names, job titles, and employment status. |
| get_projectsA | Fetch all PSA projects from Keka. Automatically pages through the entire result set and returns it combined. Use this to map project IDs found in timesheet data to project names. |
| get_clientsA | Fetch all PSA clients (customers) from Keka. Automatically pages through the entire result set and returns it combined. Use this to map a project's clientId (from get_projects) to a readable client/customer name for reporting. |
| get_leavesA | Fetch leave requests across the organization from Keka for a date range. Automatically pages through the entire result set and returns it combined. The 'from'..'to' range cannot exceed 60 days (validated before calling Keka; defaults to the last 30 days if both are omitted). Each request's numeric |
| get_holidaysA | Fetch holidays from Keka's holiday calendar(s). Keka scopes holidays per calendar rather than org-wide, so if 'calendarId' is omitted this tool first looks up every holiday calendar and then fetches and combines holidays from all of them (most tenants only have one). Each returned holiday is tagged with the calendarId/calendarName it came from. Automatically pages through every result set involved and returns it combined. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct resource (timesheet entries, project time entries, employees, projects, clients, leaves, holidays). The two timesheet tools could be confused since both fetch timesheet entries, but the descriptions clearly distinguish by scope (all vs. single project).
All tools follow a consistent get_<resource> pattern with snake_case, making the set predictable and easy to navigate. The naming convention is uniform across all seven tools.
Seven tools is well-scoped for a Keka integration covering PSA and HRIS data. Each tool serves a distinct data-fetching purpose, and the count feels appropriate for the server's apparent read-only reporting scope.
The server covers the main read-only data needs (timesheets, projects, clients, employees, leaves, holidays) but lacks write operations and some potentially useful lookups like individual employee details or project-specific leaves. For a reporting-focused server this is reasonable, but there are notable gaps if broader HRIS/PSA workflows are expected.