Clockify MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between getTimeEntries, getUserTimeEntries, and getUserTimeEntriesByName, which all retrieve time entries with slight variations in filtering. This could cause confusion for an agent trying to select the right tool for listing time entries, as the boundaries between these three tools are not entirely clear.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern throughout, such as addTimeEntry, getSummaryReport, and listProjects. However, there is a minor deviation with getUserTimeEntriesByName, which includes an extra descriptor in the name, slightly breaking the pattern compared to the others.
Tool Count5/5
With 7 tools, the count is well-scoped for a time-tracking server like Clockify. Each tool serves a specific function in managing time entries, projects, and users, and none appear redundant or out of place for the domain.
Completeness4/5
The toolset covers core time-tracking operations well, including adding time entries, retrieving reports, and listing projects and users. However, there are minor gaps, such as no tools for updating or deleting time entries, which could limit full lifecycle management but are not critical for basic workflows.
Average 3.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Add' implies a write operation, the description doesn't disclose whether this requires authentication, what permissions are needed, whether the operation is idempotent, what happens on failure, or what the response contains. For a mutation tool with zero annotation coverage, this represents significant gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, and there's no redundancy or unnecessary elaboration. This represents optimal conciseness for a basic tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after the time entry is added, what the return value might be, error conditions, authentication requirements, or how this tool relates to the sibling retrieval tools. For a tool that presumably modifies data in a time tracking system, more contextual information would be expected.
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?
With 100% schema description coverage, the input schema already documents all four parameters thoroughly. The description adds no additional semantic context about the parameters beyond what's in the schema. It doesn't explain relationships between parameters (e.g., that 'end' should be after 'start'), format expectations beyond ISO8601, or constraints on values. The baseline score of 3 reflects adequate but minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('time entry to a project'), making the purpose immediately understandable. It distinguishes from sibling tools like getTimeEntries or listProjects by focusing on creation rather than retrieval. However, it doesn't specify what constitutes a 'time entry' in this context, leaving some ambiguity about the resource being manipulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like getTimeEntries and getUserTimeEntries that retrieve time entries, there's no indication whether this tool should be used for creating new entries versus updating existing ones, or what prerequisites might be needed. The description offers no context about appropriate use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves a summary report but does not disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format is. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes key optional parameters. There is no wasted text, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a reporting tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, output format, and usage context, which are crucial for an AI agent to effectively invoke the tool without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (start, end, userIds, projectIds) with descriptions. The description adds marginal value by mentioning the optional nature of userIds and projectIds, but does not provide additional semantics beyond what the schema specifies, aligning with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('summary report of hours by user/project'), specifying what the tool does. However, it does not explicitly differentiate from sibling tools like 'getTimeEntries' or 'getUserTimeEntries', which might also retrieve time-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'getTimeEntries' or 'getUserTimeEntries'. It mentions optional parameters but does not specify contexts, prerequisites, or exclusions for usage, leaving the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it lists time entries for the authenticated user, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, or error handling. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the main purpose in the first sentence and adding parameter details in the second. There's no wasted text, making it efficient, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., format, fields), authentication needs, or error cases. For a tool with no structured support, this leaves the agent under-informed about critical usage aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents both parameters with descriptions. The description adds minimal value by mentioning the parameters are optional and in ISO8601 format, but this doesn't go beyond what the schema provides, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('time entries for the authenticated user'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'getUserTimeEntries' or 'getUserTimeEntriesByName', which appear similar, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getUserTimeEntries' or 'getUserTimeEntriesByName'. It mentions optional parameters but doesn't specify contexts or exclusions for usage, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('List') but doesn't disclose behavioral traits such as pagination, sorting, rate limits, error conditions, or what 'authenticated user' entails. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all projects') and adds essential scope ('for the authenticated user'). There is zero waste, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It lacks details on return format (e.g., list structure, fields), error handling, or authentication requirements, which are crucial for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't add param details, earning a baseline score of 4 for not overloading with unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects'), specifying scope ('all projects for the authenticated user'). It distinguishes from siblings like 'getTimeEntries' or 'listUsers' by focusing on projects, but doesn't explicitly differentiate from potential similar tools like 'getProjects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or compare to siblings like 'getSummaryReport' or 'addTimeEntry' for project-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists users but doesn't describe any behavioral traits such as pagination, rate limits, authentication needs, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) but lack of annotations and output schema, the description is incomplete. It doesn't provide enough context about behavioral aspects like output format or usage constraints, which are necessary for the agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all users in the workspace'), making the tool's purpose immediately understandable. It doesn't distinguish from sibling tools like 'getUserTimeEntries' or 'getUserTimeEntriesByName', which focus on time entries rather than user listings, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists time entries and mentions optional date parameters, but it doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, error handling, or what the return format looks like. For a read operation with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second adds optional parameter details. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral constraints, which are crucial for an AI agent to use the tool correctly. The description should provide more context to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (userId, start, end) with descriptions. The description adds minimal value by noting that start and end are optional and in ISO8601 format, but this is redundant with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List time entries for a specified user.' It specifies the verb ('List'), resource ('time entries'), and target ('specified user'), making the function unambiguous. However, it doesn't distinguish this tool from its sibling 'getTimeEntries' (which likely lists all time entries vs. user-specific), missing full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'for a specified user,' suggesting this is for user-specific queries, but it doesn't explicitly state when to use this tool versus alternatives like 'getTimeEntries' or 'getUserTimeEntriesByName.' No guidance on prerequisites, exclusions, or specific contexts is provided, leaving usage somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the matching behavior ('case-insensitive, partial match allowed') and date format ('ISO8601'), which aren't in the schema. However, it doesn't describe critical behaviors like pagination, rate limits, authentication needs, error conditions, or what the return format looks like (especially problematic since there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first clause states the core purpose, followed by key behavioral details and parameter notes. Every sentence earns its place with no wasted words. The structure efficiently communicates essential information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (filtered listing with partial matching), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what the return values look like (structure, fields, pagination), error conditions, or authentication requirements. While it covers the basic operation and parameters, critical context for proper tool invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds marginal value by reiterating that 'start' and 'end' are optional and specifying the ISO8601 format (which is already in the schema descriptions). It doesn't provide additional semantic context beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List time entries for a user by name' - a specific verb ('List') and resource ('time entries') with a key constraint ('by name'). It distinguishes from sibling tools like 'getTimeEntries' (which likely lacks user filtering) and 'getUserTimeEntries' (which might use user ID instead of name), though this differentiation isn't explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the 'by name' specification and optional date parameters, suggesting this tool is for filtering time entries by user name rather than ID. However, it doesn't explicitly state when to use this vs. alternatives like 'getUserTimeEntries' (which might use user ID) or 'getTimeEntries' (which might list all entries). No explicit when-not-to-use guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/inakianduaga/clockify-mcp'

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