Clockify MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between time entry tools: create_time_entry, log_time, and start_timer all handle time tracking, with descriptions indicating preferences (e.g., 'prefer start_timer or log_time instead'), which could cause confusion. Similarly, stop_current_timer and stop_timer are redundant. However, other tools like get_projects, create_task, and get_reports are clearly differentiated.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. Examples include create_project, get_projects, start_timer, and update_time_entry. This predictability makes it easy for agents to understand and navigate the toolset without confusion from mixed naming conventions.
Tool Count3/5
With 21 tools, the count is borderline high for a time-tracking server, leaning toward heavy. While it covers many aspects of Clockify's functionality, some tools like stop_timer and stop_current_timer could be consolidated to reduce redundancy. A more streamlined set of 15-18 tools might be more appropriate for the scope.
Completeness5/5
The toolset provides comprehensive coverage for time-tracking and project management in Clockify. It includes CRUD operations for projects, tasks, tags, and time entries, along with reporting (detailed and summary), user and workspace management, and timer controls. There are no obvious gaps; agents can perform full workflows from setup to reporting without dead ends.
Average 3.2/5 across 21 of 21 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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?
No annotations are provided, so the description carries full burden. It mentions 'auto-detects workspace', which hints at default behavior, but fails to disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what happens if parameters are omitted. For a tool with 5 parameters and no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, which is efficient and front-loaded. However, it may be overly brief given the tool's complexity, potentially sacrificing clarity for brevity. Every word earns its place, but more detail could improve usefulness.
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 has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the report contains, how entries are structured, or what the return value looks like. For a 'detailed report' tool with multiple filters, this lack of context makes it inadequate for effective use.
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 fully documents all 5 parameters. The description adds minimal value beyond the schema by implying workspace auto-detection for the 'workspaceId' parameter, but doesn't provide additional context for other parameters like date formats or filtering logic. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a 'detailed report with individual entries' and mentions 'auto-detects workspace', which provides a basic purpose. However, it lacks specificity about what type of report (e.g., time tracking, financial) and doesn't clearly differentiate from sibling tools like 'get_summary_report' or 'get_time_entries', making the purpose somewhat vague.
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 mentions 'auto-detects workspace' but doesn't explain when this is beneficial or when to choose this over similar tools like 'get_summary_report' or 'get_time_entries'. No explicit when/when-not instructions or alternative references are provided.
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 creates a new project and auto-detects workspace, but lacks details on permissions required, whether creation is idempotent, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this is insufficient.
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 with no wasted words. It's front-loaded with the core purpose and includes a useful behavioral note about workspace auto-detection, making it appropriately concise.
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 incomplete. It doesn't cover behavioral aspects like error handling, response format, or dependencies, leaving significant gaps for an AI agent to use it correctly.
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 fully documents all 5 parameters. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate when 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 action ('Create') and resource ('new project'), and mentions the auto-detection of workspace, which provides useful context. However, it doesn't explicitly differentiate this from sibling tools like 'create_task' or 'create_tag' beyond the resource type.
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 minimal guidance, mentioning auto-detection of workspace but not when to use this tool versus alternatives like 'get_projects' for checking existing projects or 'create_task' for related resources. No explicit when/when-not instructions or prerequisites are given.
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 states 'Create a new tag', implying a mutation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling, or response format. The auto-detection note adds some context but is insufficient for a mutation 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 extremely concise with two short sentences that are front-loaded and waste no words. Every part ('Create a new tag', 'Auto-detects workspace') adds value, making it efficient 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 the tool's complexity as a mutation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, errors), output values, and comprehensive usage guidelines. The high schema coverage helps, but overall, it doesn't provide enough context for safe and effective use.
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 both parameters (workspaceId and name) with descriptions. The description adds 'Auto-detects workspace', which provides extra meaning for workspaceId's default behavior, but doesn't elaborate on name constraints or other semantics. This meets 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 action ('Create a new tag') and resource ('tag'), which is specific and unambiguous. It distinguishes from siblings like 'get_tags' by indicating a write operation. However, it doesn't explicitly differentiate from other creation tools like 'create_project' or 'create_task' beyond the resource type.
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 minimal guidance with 'Auto-detects workspace', hinting at when to use the workspaceId parameter, but offers no explicit when-to-use advice, no mention of prerequisites (e.g., permissions), and no alternatives (e.g., when to use this vs. other tag-related tools). It lacks context for selection among siblings.
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 mentions 'Auto-detects workspace' as a helpful trait, but fails to cover critical aspects like permissions needed, whether deletion is reversible, rate limits, or error handling. This is inadequate for a destructive operation.
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 with zero waste. It front-loads the core action and includes a useful behavioral note, 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 this is a destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on permissions, reversibility, response format, or error cases, which are essential for safe and effective use by an AI agent.
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 both parameters fully. The description adds no additional meaning beyond implying workspace auto-detection, which is partially covered in 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 verb ('Delete') and resource ('a time entry by ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_time_entry' or 'get_time_entries' beyond the action itself, which prevents a perfect score.
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 'update_time_entry' for modifications or 'get_time_entries' for viewing. It also lacks prerequisites or exclusions, leaving usage context implied at best.
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 full burden for behavioral disclosure. It mentions 'Auto-detects workspace' which provides some behavioral context about default parameter handling. However, it doesn't describe important aspects like whether this is a read-only operation, what format the list returns, if there's pagination, rate limits, or authentication requirements. For a tool with zero annotation coverage, this leaves significant gaps.
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 with just two short sentences that communicate the core functionality and one key behavioral aspect. Every word earns its place, and the information is front-loaded with the primary purpose stated first. There's zero wasted verbiage or redundancy.
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 data retrieval tool with no annotations and no output schema, the description should do more to explain what the tool returns and any behavioral constraints. While the purpose is clear, important context is missing about the return format, pagination, error conditions, or how this fits within the broader system of sibling tools. The description is too minimal for a tool that presumably returns client 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 fully documents the single parameter. The description adds marginal value by mentioning 'Auto-detects workspace' which implies the workspaceId parameter defaults to the active workspace, but this is already stated in the schema description. The description doesn't provide additional parameter semantics beyond what's in the structured schema.
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 ('clients'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'get_workspace_users' or 'get_tags', but the resource specificity ('clients') provides some differentiation. The mention of 'Auto-detects workspace' adds useful context about default behavior.
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. While it mentions auto-detection of workspace, it doesn't explain when you'd want to override this with the workspaceId parameter or how this tool relates to other get_* tools in the sibling list. The description lacks any 'when-to-use' or 'when-not-to-use' context.
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 full burden for behavioral disclosure. While it mentions auto-detection of workspace (helpful context), it doesn't address important behavioral aspects: whether this creates new records or updates existing ones, what permissions are required, whether it's idempotent, what happens on failure, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 - just two brief sentences that communicate essential information without any wasted words. It's front-loaded with the core purpose and includes only necessary additional context about workspace auto-detection.
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?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, what happens on success/failure, or how it differs from similar sibling tools. The auto-detection hint is helpful but insufficient for proper contextual understanding.
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 6 parameters thoroughly. The description adds minimal value beyond the schema - it only reinforces the duration format example ('1h30m') which is already in the schema. No additional parameter semantics are provided, so baseline 3 is appropriate.
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: 'Log completed time with duration like "1h30m"'. It specifies the action (log), resource (time), and format requirement. However, it doesn't explicitly differentiate from sibling tools like 'create_time_entry' or 'update_time_entry', which appears to be a related functionality.
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 mentions 'Auto-detects workspace' which provides some context about default behavior, but offers no explicit guidance on when to use this tool versus alternatives like 'create_time_entry' or 'update_time_entry'. There's no mention of prerequisites, dependencies, or specific scenarios where this tool is preferred.
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 full burden for behavioral disclosure. It mentions 'auto-detects workspace' which adds some context about default behavior, but fails to disclose critical mutation traits: permission requirements, whether updates are reversible, what happens to unspecified fields, or error conditions. For a write operation with zero annotation coverage, this is insufficient.
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 - just 8 words in a single sentence. It's front-loaded with the core purpose ('Update a time entry by ID') and adds one useful behavioral note ('Auto-detects workspace'). Every word earns its place with zero redundancy.
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?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, permission requirements, or how it differs from sibling time-tracking tools. The 100% schema coverage helps with parameters, but behavioral context is severely lacking.
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 7 parameters thoroughly. The description adds minimal value beyond the schema - only implying that workspaceId has auto-detection behavior. No additional parameter semantics, constraints, or usage examples are provided, 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 verb ('update') and resource ('time entry by ID'), making the purpose unambiguous. It distinguishes from siblings like 'create_time_entry' and 'delete_time_entry' by specifying update functionality. However, it doesn't explicitly differentiate from other update-like operations in the sibling list.
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 minimal usage guidance - only mentioning that it 'auto-detects workspace' which suggests some context about workspace selection. No explicit guidance on when to use this vs alternatives like 'log_time' or 'stop_timer' for time tracking operations, nor any prerequisites or exclusions.
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 what data is returned but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether it's a read-only operation (implied by 'Get' but not explicit).
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 ('Get current user info') and adds a specific detail ('including active workspace ID') without any wasted words. It's appropriately sized for a simple tool.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what data is returned but lacks context on authentication, errors, or usage scenarios, making it minimally viable for an agent to invoke 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 schema description coverage at 100%. The description doesn't need to add parameter details, so it appropriately focuses on output semantics ('current user info including active workspace ID'), earning a baseline score for zero-parameter tools.
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 the resource 'current user info', specifying it includes 'active workspace ID'. It distinguishes this from sibling tools that focus on projects, tasks, time entries, etc., but doesn't explicitly differentiate from other user-related tools (none exist in siblings).
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. The description implies it retrieves user-specific data, but there's no mention of prerequisites (e.g., authentication) or comparison to other tools for user information (none in siblings).
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 mentions 'Auto-detects workspace/user', which adds useful context about default behavior. However, it fails to disclose critical traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what the return format looks like (e.g., list of entries, pagination). For a retrieval tool with no annotations, this leaves significant gaps.
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 with two sentences that efficiently convey key information: the core action and filtering capabilities. It's front-loaded with the main purpose. However, the second sentence could be slightly more structured (e.g., clarifying that auto-detection applies when parameters are omitted).
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?
Given no annotations and no output schema, the description is incomplete for a tool with 6 parameters. It covers the purpose and some behavioral context (auto-detection) but lacks details on return values, error handling, or usage constraints. For a retrieval tool in a server with many siblings, more guidance on output and differentiation would improve completeness.
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 6 parameters thoroughly. The description adds minimal value by mentioning 'period filter' and 'Auto-detects workspace/user', which aligns with parameters like 'period', 'workspaceId', and 'userId' but doesn't provide additional semantics beyond what's in 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 verb 'Get' and resource 'time entries', making the purpose evident. It distinguishes itself from siblings like 'get_detailed_report' or 'get_summary_report' by focusing on time entries rather than reports. However, it doesn't explicitly differentiate from 'get_projects' or 'get_tags', which are also retrieval tools but for different resources.
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 'Supports period filter' and 'Auto-detects workspace/user', suggesting it's for retrieving time entries with optional filtering. However, it lacks explicit guidance on when to use this versus alternatives like 'get_detailed_report' for more comprehensive data or 'get_summary_report' for aggregated insights. No exclusions or prerequisites are stated.
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 full burden for behavioral disclosure. It mentions 'Auto-detects workspace' which adds useful context about default behavior, but fails to describe critical aspects like whether this tool requires authentication, what happens if a timer is already running, error conditions, or the response format. For a mutation tool with zero annotation coverage, this is insufficient.
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 with just two sentences that both add value. The first sentence states the core purpose, and the second provides important contextual guidance about workspace auto-detection and project ID sourcing. There's no wasted language or redundancy.
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?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. While concise, it lacks information about authentication requirements, error handling, what the tool returns, whether it's idempotent, or how it interacts with other timer-related tools. The agent would need to guess about important behavioral 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?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score. It doesn't explain parameter relationships or provide usage examples.
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 ('Start a timer') and resource ('timer'), making the purpose immediately understandable. It distinguishes from sibling tools like 'stop_timer' or 'get_running_timer' by specifying the starting action, though it doesn't explicitly contrast with all alternatives like 'log_time'.
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 provides some usage context by mentioning 'Auto-detects workspace' and referring to 'get_projects for project IDs', which implies when to use related tools. However, it lacks explicit guidance on when to choose this tool over alternatives like 'log_time' or 'create_time_entry', and doesn't specify prerequisites or exclusions.
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 full burden but only mentions 'auto-detects workspace' as behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are needed, how results are formatted, whether pagination exists, or any rate limits. For a reporting tool with 4 parameters, this is inadequate behavioral disclosure.
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 (one sentence) with zero wasted words. It's front-loaded with the core purpose and includes one important behavioral note. Every element earns its place.
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 reporting tool with 4 parameters and no output schema, the description is minimally adequate. It covers the basic purpose but lacks important context about return format, data scope, or behavioral constraints. With no annotations and no output schema, more completeness would be expected for proper agent usage.
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 4 parameters thoroughly. The description adds minimal value by implying grouping functionality ('grouped by project/user') and workspace auto-detection, but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when 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 generates a 'summary report grouped by project/user' with 'auto-detects workspace' functionality, providing specific verb (get) and resource (summary report). It distinguishes from siblings like get_detailed_report by specifying 'summary' nature, though it doesn't explicitly contrast with other reporting tools.
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 for generating grouped summary reports and mentions auto-detection of workspace, but provides no explicit guidance on when to use this versus alternatives like get_detailed_report or get_time_entries. No exclusions or prerequisites are mentioned.
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 full burden for behavioral disclosure. It mentions 'Auto-detects workspace' which adds useful context about default behavior, but fails to describe critical aspects like whether this is a read-only operation, pagination, rate limits, authentication needs, or what format the returned tags have. For a tool with no annotation coverage, this leaves significant gaps.
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 with just two short sentences that each add value. The first sentence states the core purpose, and the second adds important behavioral context about workspace detection. There is zero wasted language or redundancy.
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 simple list operation with one optional parameter and no output schema, the description provides adequate but minimal context. It covers the basic purpose and workspace detection behavior, but doesn't address what the return data looks like, error conditions, or how it differs from other get_* tools. The absence of annotations and output schema means more descriptive context would be helpful.
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 fully documents the single optional parameter 'workspaceId'. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
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 all tags') and resource ('tags'), making the purpose immediately understandable. It distinguishes itself from siblings like 'create_tag' by being a read operation. However, it doesn't specify whether this returns all tags globally or within a specific scope beyond workspace detection.
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 when needing to retrieve tags, with the 'Auto-detects workspace' hint suggesting it's context-aware. However, it provides no explicit guidance on when to use this versus alternatives like 'get_projects' or 'get_workspaces', nor does it mention prerequisites or exclusions.
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 for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't disclose any behavioral traits like required permissions, whether the task is immediately active, error conditions, or what happens on success. This leaves significant gaps for a mutation 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?
The description is extremely concise with just two sentences that are front-loaded and waste no words. Every sentence earns its place by stating the core purpose and providing essential usage guidance.
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 incomplete. It doesn't explain what happens after creation (e.g., returns task ID, error handling), behavioral constraints, or how it differs from sibling creation tools. The 100% schema coverage helps parameters but doesn't compensate for missing behavioral context.
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 4 parameters thoroughly. The description adds minimal value beyond the schema by reinforcing the need for projectId via 'Use get_projects first,' but doesn't provide additional semantic context about parameters like workspaceId defaults or assigneeIds format.
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 ('Create a task') and target resource ('in a project'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'create_project' or 'create_tag' beyond the resource type, which prevents a perfect score.
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 to 'Use get_projects first to get project ID,' which gives clear context for when to use this tool. However, it doesn't mention when NOT to use it or alternatives for similar operations, such as whether 'create_project' should be used first if no project exists.
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 of behavioral disclosure. It only states it's a list operation, but doesn't mention whether it's paginated, what permissions are required, if it's rate-limited, or what the return format looks like. For a read tool with zero annotation coverage, this is a significant gap in behavioral context.
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, front-loaded with the core purpose and followed by a concise usage tip. Every sentence earns its place with no wasted words, making it highly efficient 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 the tool has no annotations and no output schema, the description is incomplete. It doesn't explain behavioral traits like pagination or permissions, and while it hints at the return type ('tasks'), it doesn't detail the structure or fields. For a tool with 2 parameters and no structured output, more context is needed to be fully helpful.
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 both parameters ('workspaceId' and 'projectId') with descriptions. The description adds value by reinforcing the need to use 'get_projects' for the 'projectId', but doesn't provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when 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 verb ('List') and resource ('tasks for a project'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'get_time_entries' or 'get_summary_report', which might also involve task-related data, so it lacks 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by instructing to 'Use get_projects first to get project ID,' which is a helpful prerequisite. However, it doesn't specify when to use this tool versus alternatives like 'get_time_entries' or 'get_detailed_report' for task-related queries, so it lacks explicit exclusions or named alternatives.
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 full burden for behavioral disclosure. It states the tool 'checks' status and 'auto-detects,' which implies a read-only, non-destructive operation. However, it doesn't disclose important behavioral traits: what specific data is returned (e.g., timer details, elapsed time), error conditions (e.g., what happens if no timer is running), or performance characteristics. The description is minimal and leaves key behavioral aspects unspecified.
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 (two short sentences) with zero wasted words. The first sentence states the core purpose, and the second adds important behavioral context. Every element earns its place, and the information is front-loaded with the primary function stated first.
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?
Given the tool's low complexity (single optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and auto-detection behavior but leaves significant gaps: no information about return values (critical for a status check tool), no error handling details, and no context about how this integrates with timer control tools. For a status-checking tool, the description should ideally specify what information is returned.
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 description adds meaningful context beyond the input schema. While the schema has 100% coverage for the single parameter (workspaceId with default behavior documented), the description's 'Auto-detects workspace/user' provides crucial semantic context about automatic detection logic that isn't captured in the schema's parameter description. This compensates for the schema's technical focus with practical usage 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 tool's purpose: 'Check if timer is running' specifies the verb (check) and resource (timer status). It distinguishes from siblings like start_timer/stop_timer by focusing on status checking rather than control. However, it doesn't explicitly differentiate from other read operations like get_time_entries.
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 provides implied usage context through 'Auto-detects workspace/user,' suggesting it's for checking current timer status without manual identification. However, it lacks explicit guidance on when to use this versus alternatives like get_time_entries (which might show timer data) or stop_current_timer (which requires knowing if a timer is running). No when-not-to-use or prerequisite information is provided.
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 of behavioral disclosure. It mentions the tool lists workspaces and hints at its use for obtaining IDs, but fails to describe key behaviors such as whether it returns all workspaces at once (e.g., pagination), what data fields are included, or any rate limits or permissions required. This leaves significant gaps for an agent to understand how to use it effectively.
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 with two short sentences that are front-loaded and waste no words. Every part adds value: the first sentence states the core purpose, and the second provides practical usage advice, making it efficient and well-structured.
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?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a minimum viable explanation. However, it lacks details on return values (e.g., what data is included in the list) and behavioral aspects like pagination or permissions, which are important for completeness even in simple tools. This makes it just sufficient but with clear gaps.
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, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't waste space on parameters, earning a high score. A perfect 5 is reserved for cases where parameter semantics are explicitly addressed when needed.
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 ('all workspaces'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_workspace_users' or 'get_clients' that might also relate to workspace data, so it doesn't reach the highest score.
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 provides implied usage guidance by stating 'Call first if you need workspace IDs,' which suggests this tool should be used early in workflows to obtain IDs for other operations. However, it doesn't explicitly state when not to use it or name alternatives among siblings, leaving some ambiguity.
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 full burden. It discloses that the tool auto-detects workspace and is intended as a first call to get IDs, which are useful behavioral traits. However, it doesn't mention pagination, rate limits, permissions needed, or what format the list returns.
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 two short sentences, with zero wasted words. It's front-loaded with the core purpose and follows with important usage context. Every sentence earns its place.
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 simple list tool with 2 parameters and no output schema, the description provides adequate but minimal context. It covers the purpose and some behavioral aspects but lacks details about return format, pagination, or error conditions that would be helpful for an agent.
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 fully documents both parameters. The description adds no additional parameter information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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', making the purpose immediately understandable. It distinguishes from siblings by specifying it's for getting project IDs, but doesn't explicitly differentiate from other list tools like get_clients or get_tags.
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 provides implied usage guidance with 'Call first to get project IDs' and mentions auto-detection of workspace, but doesn't explicitly state when to use this versus alternatives like get_project_tasks or get_workspaces. No clear exclusions or when-not-to-use guidance is provided.
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 full burden for behavioral disclosure. It mentions auto-detection behavior, which is helpful, but doesn't address critical aspects like whether this is a read-only operation, what permissions are required, how results are formatted (list structure, pagination), or error conditions. For a tool with zero annotation coverage, this leaves significant gaps.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second adds important behavioral context about default behavior. There's zero wasted language or redundancy.
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?
Given the tool's moderate complexity (list operation with one optional parameter), no annotations, and no output schema, the description provides basic completeness but lacks details about return format, pagination, authentication requirements, or error handling. It's adequate as a minimum viable description but has clear gaps for effective agent use.
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 schema already fully documents the single parameter. The description adds the auto-detection context ('defaults to active workspace'), which provides useful semantic meaning beyond the schema's technical description. This meets 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 action ('List users') and resource ('in workspace'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling user-related tools (though none exist in the provided list), so it doesn't reach the highest score.
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 clear context about when to use it ('Auto-detects workspace if not specified'), which helps the agent understand the default behavior. However, it doesn't explicitly state when NOT to use it or mention alternatives for user-related operations, preventing a perfect score.
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. It discloses key behavioral traits: it stops a timer, auto-detects workspace/user, and implies it targets the 'current' or 'running' timer. However, it lacks details on permissions needed, error conditions (e.g., if no timer is running), or what happens after stopping (e.g., does it log the time?). This is adequate but has gaps for a mutation 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?
The description is extremely concise with just two short sentences that are front-loaded with the core action. Every word earns its place, with no wasted text, making it easy for an AI agent to parse quickly and accurately.
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?
Given the tool has 2 parameters with full schema coverage but no annotations or output schema, the description is minimally complete. It covers the basic action and auto-detection behavior, but for a mutation tool that stops a timer, it lacks details on side effects, success indicators, or error handling. This is adequate but leaves room for improvement in contextual richness.
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 fully documents the two parameters (workspaceId and end). The description adds no parameter-specific information beyond implying auto-detection relates to workspaceId. Since the schema handles the heavy lifting, a baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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 ('Stop running timer') and the resource ('timer'), making the purpose immediately understandable. It distinguishes from sibling tools like 'stop_timer' by specifying 'current' timer and auto-detection behavior, though it doesn't explicitly contrast with 'stop_timer' which might have different parameter requirements.
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 by stating 'Auto-detects workspace/user,' suggesting this tool should be used when the agent wants to stop whatever timer is currently running without specifying workspace/user. However, it doesn't explicitly state when to use this vs. 'stop_timer' or provide clear alternatives or exclusions.
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 of behavioral disclosure. While it mentions the tool is 'low-level,' it doesn't explain what that entails (e.g., whether it requires specific permissions, how it handles errors, or if it has side effects like affecting billing). The description lacks details on behavioral traits beyond the basic action.
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 with only two short sentences, front-loading the core purpose and immediately following with usage guidance. Every word serves a clear purpose, with no wasted text or redundancy.
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?
Given the tool's complexity (7 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error handling, or return values, which are critical for a creation tool. However, the usage guidance and clear purpose provide some context.
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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between parameters or providing examples. This meets 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 ('Create') and resource ('time entry'), making the purpose immediately understandable. It distinguishes this tool from siblings by labeling it as 'low-level' and mentioning alternatives, though it doesn't specify what makes it low-level versus the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by stating 'Prefer start_timer or log_time instead,' which clearly indicates when not to use this tool and names specific alternatives. This helps the agent understand the tool's role in the context of sibling tools.
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 for behavioral disclosure. It only states this is 'low-level' without explaining what that means operationally (e.g., requires manual ID specification vs. automatic detection, potential for errors if wrong IDs are provided). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two brief sentences that each serve a clear purpose: stating the action and providing critical usage guidance. There is zero wasted text, and the most important information (the alternative tool) is front-loaded.
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?
Given the tool's apparent complexity (stopping a timer with ID parameters) and lack of both annotations and output schema, the description is minimally adequate. It identifies the tool and provides crucial sibling differentiation, but fails to explain behavioral implications of being 'low-level' or what happens when the tool executes.
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 fully documents both parameters (workspaceId and userId) with their types and default behaviors. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation.
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 ('Stop') and resource ('timer'), making the purpose immediately understandable. However, it doesn't specify what 'timer' refers to in this context (e.g., a time-tracking timer) or what stopping entails, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by stating 'Prefer stop_current_timer instead.' This clearly indicates when NOT to use this tool and names a specific alternative, which is ideal for helping an agent choose between sibling tools.
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-server MCP server](https://glama.ai/mcp/servers/Yikizi/clockify-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Yikizi/clockify-mcp-server)

Score Badge

Copy to your README.md:

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

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/Yikizi/clockify-mcp-server'

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