What can you do with this server?

The Timely MCP Server provides access to the Timely.mn v3 time-attendance API, enabling HR and attendance management functions: * timely_employer_info – Look up a registered company's name using its 7-digit register number. * timely_overview_attd – Generate a paginated, company-wide attendance report for a date range, with an optional department filter, including worked days/hours, late arrivals, absences, overtime, leave, and vacation. * timely_employee_attd – Retrieve an attendance report for a single employee (identified by register number and/or phone) between two dates, showing supposed vs. actual worked days and hours. * timely_employee_info – Fetch an employee's full profile — name, register number, phone, salary, and bank details — identified by register number, TIN, and/or phone.

How do I use Timely MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Timely MCP Server What's the company-wide attendance report for today?" 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.

Timely MCP Server

by naranmunkh

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

Timely MCP Server

An MCP server that exposes the Timely.mn v3 time-attendance API as tools for Claude and any other MCP client.

Built for UBCab Holding. One self-contained file (src/index.ts) runs two ways:

Remote (Vercel) — Vercel's Node framework invokes the file's default (req, res) handler. Live at POST https://timely-mcp.vercel.app/mcp, protected by a bearer token.
Local (stdio) — when run directly (node dist/index.js), it speaks MCP over stdio for Claude Desktop.

Tools

Tool	Endpoint	Purpose
`timely_employer_info`	`POST /v3/employer-info`	Company name lookup by 7-digit register
`timely_overview_attd`	`POST /v3/overview-attd`	Company-wide attendance report (paginated)
`timely_employee_attd`	`POST /v3/employee-attd`	One employee's attendance between two dates
`timely_employee_info`	`POST /v3/employee-info`	One employee's profile (name, salary, bank)

Login (POST /v3/login → JWT) is automatic: the token is cached and refreshed on a 401/403. Credentials are only required when a tool actually calls the API, so tools/list works without them.

Related MCP server: Tipsoi MCP

Endpoints (deployed)

POST /mcp — the MCP endpoint (bearer token required).
GET /health — returns {"status":"ok"} (no auth).

Environment variables

Variable	Required	Notes
`TIMELY_USERNAME`	yes (for API calls)	Timely API login
`TIMELY_PASSWORD`	yes (for API calls)	Timely API password
`TIMELY_MCP_AUTH_TOKEN`	yes (remote)	Secret clients send as `Bearer`. The POST endpoint fails closed without it. Generate: `openssl rand -hex 32`
`TIMELY_COMPANY_REGISTER`	no	Default 7-digit register
`TIMELY_BASE_URL`	no	Defaults to `https://api.timely.mn`

Use locally (Claude Desktop)

npm install
npm run build

{
  "mcpServers": {
    "timely": {
      "command": "node",
      "args": ["/absolute/path/to/timely-mcp/dist/index.js"],
      "env": {
        "TIMELY_USERNAME": "ubcabholding",
        "TIMELY_PASSWORD": "your-password",
        "TIMELY_COMPANY_REGISTER": "1234567"
      }
    }
  }
}

Connect to the remote endpoint

Three ways to authenticate (the endpoint accepts any of them):

1. OAuth (recommended — nothing secret in the URL). Add a custom connector with just the URL https://timely-mcp.vercel.app/mcp. The client discovers the OAuth metadata, opens a login page, and prompts for the access token (TIMELY_MCP_AUTH_TOKEN). Implemented as a stateless OAuth 2.1 + PKCE server: /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /register, /authorize, /token. Auth codes and access tokens are HMAC-signed blobs (no datastore).

2. Header (Claude Desktop JSON config).

{
  "mcpServers": {
    "timely-remote": {
      "type": "http",
      "url": "https://timely-mcp.vercel.app/mcp",
      "headers": { "Authorization": "Bearer <TIMELY_MCP_AUTH_TOKEN>" }
    }
  }
}

3. Token in URL path (for clients that can't send a header): https://timely-mcp.vercel.app/mcp/<TIMELY_MCP_AUTH_TOKEN>

Smoke test:

curl -s -X POST https://timely-mcp.vercel.app/mcp -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -H 'Authorization: Bearer <TIMELY_MCP_AUTH_TOKEN>' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Deployment notes

Vercel auto-detects this repo as a Node project and runs src/index.ts's default export as a serverless function — there is no vercel.json and no /api directory by design. Adding either reintroduced routing/entrypoint bugs.
Every push to main auto-deploys via Vercel's Git integration.
Verify the JWT field with node --env-file=.env scripts/test-login.mjs; if the token lives under a field other than token/access_token/accessToken/jwt, add it to extractToken() in src/index.ts.

Security

The deployed URL + bearer token can read employee salary and bank details. Treat both as secrets; rotate the token (openssl rand -hex 32 → update the Vercel env var → redeploy) if it leaks.

Available Tools

4 tools

timely_employee_attdA

Attendance report for a single employee between two dates. Identify the employee by register number and/or phone. Returns supposed vs. actual worked days and hours.

ParametersJSON Schema

Name	Required	Description
`company_register`	No	7-digit company register. Falls back to TIMELY_COMPANY_REGISTER.
`register`	No	Employee national register number, e.g. УУ12345678.
`phone`	No	Employee phone number.
`dateFrom`	Yes	Start date, e.g. 2023-01-01
`dateTo`	Yes	End date, e.g. 2023-01-31

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool reads and returns data ('returns supposed vs. actual worked days and hours'), implying a safe read operation. No mention of side effects or permissions, but adequate for a simple report tool.

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?

Two sentences, front-loaded with purpose and key details. No unnecessary words. Every sentence contributes meaning.

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 tool with 5 parameters and no output schema, the description partially covers usage but lacks detail on return format (e.g., per-day or aggregated). It explains identification but not date range behavior. Acceptable but not fully complete.

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?

Schema coverage is 100% with good parameter descriptions. The tool description adds value by clarifying that at least one of register or phone should be provided for identification, which is not enforced by the schema's required fields.

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 it returns an attendance report for a single employee between two dates, contrasting with sibling tools like timely_overview_attd for multiple employees. The verb 'returns' and resource 'attendance report' are specific.

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 description implies use when needing a single employee's attendance, and specifies identification via register number or phone. However, it lacks explicit guidance on when not to use or alternatives, though context with sibling tools provides implicit differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

timely_employee_infoA

Get a single employee's profile from Timely (name, register, phone, salary, bank details). Identify by register, tax id (tin_number), and/or phone.

ParametersJSON Schema

Name	Required	Description
`company_register`	No	7-digit company register. Falls back to TIMELY_COMPANY_REGISTER.
`register`	No	Employee national register number.
`tin_number`	No	Taxpayer (TIN) number.
`phone`	No	Employee phone number.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It indicates a read operation ('Get') and lists returned fields, but does not mention auth requirements, error handling, or behavior when no match is found. It is adequate but not thorough.

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?

Two concise sentences with the main purpose front-loaded. Every word adds value; no filler.

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?

Given 4 optional parameters and no output schema, the description lists return fields and identification methods. Missing error behavior, but overall sufficient for a simple get operation.

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 coverage is 100%, so the baseline is 3. The description adds value by explaining that the employee can be identified by register, tin_number, and/or phone, and notes the fallback for company_register. However, this does not significantly extend beyond the schema descriptions.

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 verb 'Get' and the resource 'a single employee's profile', listing key fields (name, register, phone, salary, bank details). It distinguishes from sibling tools that handle attendance or employer info.

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 description implies usage when needing an employee profile, but does not explicitly state when to use alternatives or provide when-not conditions. The context of sibling tool names gives some guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

timely_employer_infoA

Get organization (company) info from Timely for a given 7-digit company register. Returns the registered company name. Useful to verify a register number is valid.

ParametersJSON Schema

Name	Required	Description	Default
`company_register`	No	7-digit company register. Falls back to TIMELY_COMPANY_REGISTER.

TDQS

A4.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only mentions a read operation (returns company name) but lacks details on side effects, authentication requirements, error handling, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, efficiently conveying purpose, input, output, and a use case without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter and no output schema, the description adequately covers what the tool does, its input constraints, and its output, making it complete for an AI agent to use.

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?

Schema coverage is 100%. The description adds meaning by specifying the parameter expects a 7-digit company register and notes a fallback to TIMELY_COMPANY_REGISTER environment variable, which is useful context beyond the schema.

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 retrieves organization info given a 7-digit company register and returns the registered company name. It distinguishes itself from sibling tools that deal with employee or attendance data.

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 description provides a specific use case: verifying if a register number is valid. However, it does not explicitly state when not to use this tool or mention alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

timely_overview_attdA

Company-wide attendance report between two dates. Returns per-employee attendance detail (worked days/hours, late, absent, leave, overtime, vacation, etc.) with pagination. Set div_id to a department id, or '0' for all departments.

ParametersJSON Schema

Name	Required	Description
`company_register`	No	7-digit company register. Falls back to TIMELY_COMPANY_REGISTER.
`div_id`	No	Department id; '0' (default) = all departments.
`dateFrom`	Yes	Start date, e.g. 2023-01-01
`dateTo`	Yes	End date, e.g. 2023-01-31
`page`	No	Page number (optional).
`limit`	No	Employees per page (optional).

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the output (attendance details, pagination) but does not mention read-only nature, authorization needs, or rate limits. It is adequate but not comprehensive.

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 two concise sentences: first stating purpose and output, second providing parameter guidance. It is front-loaded and every sentence adds value.

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?

Given no output schema, the description explains the returned data (worked days/hours, late, absent, etc.) and pagination. It covers core functionality but omits response format and error conditions.

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 coverage is 100% with each parameter described. The description adds only minor rephrasing (e.g., div_id usage) and no new semantic details beyond the schema. Baseline 3 applies.

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 it is a company-wide attendance report between two dates, returning per-employee details with pagination. It differentiates from sibling tools by specifying the company-wide scope and listing specific attendance metrics.

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 description provides explicit guidance on the div_id parameter (set to department id or '0' for all departments) and implies usage for generating overall attendance reports. However, it does not directly contrast with sibling tools like timely_employee_attd.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: employee attendance, employee profile, employer info, and company-wide attendance. No overlap.

Naming Consistency4/5

All tools follow the pattern 'timely_<entity>_<info/action>', consistently using underscores and lowercase. Minor abbreviation 'attd' instead of 'attendance' slightly reduces consistency.

Tool Count4/5

With only 4 tools, the server is small but focused on core HR attendance functions. It's slightly below typical range but still appropriate for its narrow scope.

Completeness3/5

Covers essential read operations for employees, attendance, and company info, but lacks any mutation tools (create, update, delete) and other HR features like leave management.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-server
io.klokin
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
Workplace & Productivity Project Management
2
cloudtime API
io.github.julysoft
MCP server providing attendance data queries via the CloudTime API.
Workplace & Productivity
2
Sleepwalker AOAuth
ai.sleepwalker
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Agent Orchestration Developer Tools Marketing
222
LeadFoxConnect
io.github.LeadFox-Shay
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Marketing CRM
2

Related MCP Servers

timely-mcp-server
Project Management Workplace & Productivity
rollecode
F
license
Not graded
quality
A
maintenance
MCP server for Timely time tracking API. Connects Claude Code to your Timely account for reading and creating time entries, projects, tasks, and users.
Updated 6 days ago (2026-08-28 13:09 UTC)
5
Tipsoi MCP
ERP Systems
the-abraar
F
license
A
quality
B
maintenance
Read-only MCP server for the Tipsoi HRM API, exposing 15 tools to read employee data, attendance, leave, overtime, and more.
Updated 2 months ago (2026-06-29 06:36 UTC)
15
clockodo-mcp-server
Project Management Workplace & Productivity
pfaeffli
A
license
Not graded
quality
A
maintenance
Enables interaction with the Clockodo time tracking API, providing tools, prompts, and resources for time tracking, HR analytics, and team management with role-based access.
Updated 4 days ago (2026-08-30 19:49 UTC)
2
MIT
mcp-leave-management
ERP Systems Workplace & Productivity
MarriHarshaVardhan
F
license
A
quality
C
maintenance
Exposes employee leave-management operations (add employees, check balance, apply/cancel leave, view history) as MCP tools for AI clients like Claude Desktop to call directly.
Updated 2 months ago (2026-07-08 12:31 UTC)
6

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/naranmunkh/timely-mcp'

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