Server Quality Checklist

Tool Scores

• clockify_list_time_entriesB
  3.3/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full behavioral burden. It correctly conveys a read-like operation scoped to the authenticated user and comments on the user-scoped config_root case. However, it does not disclose recency limits, pagination, ordering, default time ranges, or what the response contains.

  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 only two sentences, no filler, and front-loads the core purpose before the operational config_root note. Every sentence earns its place and the structure is easy to parse.

  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?

  The description covers the core action and a notable config requirement, but there is no output schema and no annotations to fill in behavior. It does not mention how to choose this tool over today_summary or how defaults behave when optional parameters are omitted. It is adequate but has visible gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 80%, so most parameters are already documented structurally. The description adds the context that config_root should be passed when the MCP is user-scoped, but it does nothing to clarify start/end, page_size, or workspace_id behavior beyond the 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 a specific action and resource: 'Lists recent time entries for the authenticated user.' It differentiates the tool from create/get/summary siblings, though it does not explicitly contrast with today_summary. The word 'recent' leaves some ambiguity about the exact scope.

  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 gives operational guidance about config_root but says almost nothing about when to use this tool versus the many sibling timer/entry tools. No mention of alternatives like clockify_today_summary or clockify_create_time_entry, and no condition-based routing.

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

• clockify_start_timerA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It clearly identifies the main side effect of starting a new running timer and adds context about entry_method modes and existing-timer preference. It does not specify whether an already-running timer is stopped automatically, what the success response looks like, or what error/conflict behavior the caller should expect.

  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 core action is front-loaded, and the description is compact without padding. The phrase 'When description.from is template' is slightly cryptic and the sentences are dense, but 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 13-parameter, annotation-less mutation tool with no output schema, the description covers the important config and timing semantics but still leaves relevant gaps: the return value, automatic handling of a running timer, and explicit comparison to stopping or getting the current timer. This is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by explaining entry_method's automated modes (include_seconds, start rounding, overlap) and by clarifying when issue_number/issue_title must be supplied for a description template. These details are not captured by the schema property descriptions alone.

  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 opening sentence, 'Starts a new running timer,' uses a specific verb plus resource and clearly conveys the tool's core action. The word 'running' also helps distinguish it from entry-creation or timer-stopping siblings, though it never explicitly names a competing tool such as clockify_create_time_entry or clockify_stop_timer.

  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 gives useful operational context: prefer stopping any existing timer first, conditionally pass issue_number/issue_title for templates, and pass config_root when the MCP is user-scoped. It does not explicitly say when to choose this tool over stop_timer, get_running_timer, or create_time_entry, so the selection guidance is mostly implied.

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

• clockify_list_tagsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It reveals that the tool is workspace-scoped and calls out a significant prerequisite: config_root is needed in user-scoped mode. However, it does not mention output format, potential errors, or authentication requirements.

  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 with no filler. The first sentence states the purpose, and the second delivers a necessary configuration instruction, making it easy to parse and act on.

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

  Completeness4/5

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

  For a simple list operation with fully documented optional parameters, the description is sufficiently complete: it clarifies the workspace scope and the key config_root prerequisite under user-scoped mode. It omits output details, but the output schema is absent and the resource is straightforward.

  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 input schema already provides 100% coverage for both parameters, with detailed explanations for config_root and workspace_id. The description adds no semantic information beyond what the schema states, so the baseline score of 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 states a clear verb and resource: it 'Lists tags available in a workspace.' It is distinct from the other siblings such as list_projects, list_tasks, and list_workspaces because the resource is specifically 'tags.' However, it does not explicitly clarify what it does not do, which is why it falls slightly short of 5.

  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?

  It provides relevant usage context by noting that config_root should be passed as the repo's git toplevel when the MCP is user-scoped. It does not explicitly contrast this tool with the sibling list tools or state when to use alternatives, leaving that to inference from the name and description.

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

• clockify_list_tasksA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full responsibility for behavioral disclosure. It reveals the user-scoped config_root requirement, which is useful, but it does not disclose return behavior, pagination, failure modes, or any side effects beyond listing. 'Lists tasks' is a safe read, so the gap is moderate rather than severe.

  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 primary purpose, and reserves the second sentence for the only non-obvious usage nuance. There is no wasted wording.

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

  Completeness4/5

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

  Given simple read operation, complete param documentation in the schema, and the useful config_root clarification, the description is nearly complete. It could mention the GUI of the tool but lacks return-format or pagination details would be expected in the absence of an output schema.

  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 project_id, config_root, and workspace_id in detail. The description adds no new parameter semantics beyond what the schema states, so baseline value 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 a specific action and resource: listing tasks for a project. It does not explicitly differentiate from sibling tools like clockify_ensure_task or clockify_list_tags, though the added 'often mapped 1:1 to GitHub labels' context gives useful semantic framing.

  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 offers meaningful usage context by telling users to pass config_root as the repo's git toplevel when the MCP is user-scoped. However, it gives no guidance on when to choose this tool over related siblings or when workspace_id should be set.

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

• clockify_list_workspacesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses that the list is scoped to the authenticated user and hints at user-scoped configuration behavior, but it does not describe output shape, pagination, or behavior when no workspaces exist. Still, 'Lists' implies a non-mutating 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?

  Two tightly written sentences with no filler. The core purpose is front-loaded, and the config_root usage guidance is a single clarifying addition. Every sentence earns its place.

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

  Completeness4/5

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

  This is a low-complexity listing tool with a single well-documented parameter and no output schema. The description gives enough behavioral context (auth scope and config_root usage) for a competent agent to call it. Minor gaps like response format are not critical for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already thoroughly documents config_root, including resolution instructions and caveats. The description adds marginal value by tying config_root to the 'user-scoped' condition, which is not in the schema. This is a modest but real addition over a strong baseline.

  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 'Lists' and the resource 'workspaces,' with the scope 'available to the authenticated user.' Though it does not explicitly name a sibling alternative, the resource itself separates it from the many list_project/list_task/list_tag siblings.

  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 a conditional usage instruction for config_root ('when this MCP is user-scoped'), which is a form of practical guidance. It does not explain when to prefer this tool over alternative list-related tools, leaving selection to be inferred from the resource name.

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

• clockify_today_summaryA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral transparency burden. 'Summarizes' does imply a read-only operation, and the output fields are clear, which is helpful. However, the description does not address timezone semantics for 'today', behavior if config_root is missing or misconfigured, or any side effects. It provides adequate but not rich behavioral detail.

  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 compact and front-loaded with the core capability and output fields first. The second sentence adds exactly one relevant edge to call correctly now, and no filler or redundant restatement appears.

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

  Completeness4/5

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

  Without an output schema, the description still communicates what the tool returns. It also incorporates important context about config_root scoping. It falls slightly short of a 5 because it does not clarify timezone semantics for 'today' or explicitly position itself relative to list_time_entries, which is the most natural sibling alternative.

  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 both config_root and workspace_id are already well documented in the schema. The description adds a small amount of value by mentioning the user-scoped config_root scenario, but it does not materially improve parameter understanding beyond the existing schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Summarizes today's tracked time,' with concrete outputs (total duration, entry count, per-project totals). This clearly differentiates it from sibling tools like list_time_entries, which covers raw entry retrieval, and get_running_timer, which covers the currently active timer.

  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 when to use the tool: whenever a summary of today's tracked time is needed. It also gives useful config_root guidance for the current scope. However, it does not explicitly state when to choose this over list_time_entries, create_time_entry, or other siblings, nor does it exclude alternatives, so the usage guidance remains mostly contextual and implicit.

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

• clockify_get_userA
  3.9/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It clearly states a read-only behavior ('Returns...') and even names the included workspace IDs, but it does not describe authentication requirements, failure modes, or the behavioral implication of omitting config_root, which is optional per the 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?

  Two sentences, no filler. The high-level behavior comes first, followed by a focused parameter condition. Excellent front-loading and structure.

  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 one-parameter getter, the description is mostly adequate and tells the agent what it returns. But it does not explain how to detect that the MCP is user-scoped, what happens if config_root is omitted, or how this relates to clockify_list_workspaces when both provide workspace IDs.

  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 schema already documents config_root with 100% coverage and detailed resolution instructions. The description adds a meaningful condition—'when this MCP is user-scoped'—which explains when to supply the optional parameter. This goes slightly beyond the schema's baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a precise verb and resource: 'Returns the authenticated Clockify user, including active and default workspace IDs.' This is distinct among siblings, and the output is specified, so an agent can distinguish it from other clockify_* tools without opening schemas.

  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 gives usage guidance for the parameter ('Pass config_root as that repo's git toplevel when this MCP is user-scoped'), but it does not explicitly tell an agent when to prefer this tool over alternatives such as clockify_list_workspaces or clockify_get_config. The tool's use is implied rather than explicitly stated.

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

• clockify_ensure_projectA
  4/5.0
  Behavior4/5

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

  With no annotations present, the description carries the full burden and it does reveal the key behavioral trait: this tool has a possible side effect and creates a project if it does not already exist. It also discloses idempotent behavior and the default-name resolution path. It does not describe the return value or all side effects, but the core mutation is stated clearly.

  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 definition is concise and front-loaded: behavioral verb first, then default name resolution, then a focused note about config_root. No empty phases or redundant restatements of the tool name.

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

  Completeness4/5

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

  Given the tool's simplicity, the description plus the complete parameter schema cover project lookup/defaults, config_root handling, and workspace override. The remaining gap is the lack of an explicit output shape or success/error cues, which matters somewhat more than because no output schema is present.

  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 three parameters. The description adds only a brief hint about config_root's role; it doesn't materially extend the parameter semantics beyond what the schema already says.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Finds a project by name or creates it', which names the exact resource and behavior and clearly differentiates the idempotent ensure operation from sibling read-only tools like clockify_list_projects. The agent knows what the tool is for without inferring.

  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 gives useful context: it explains fallback name resolution and what to pass for config_root in a user-scoped MCP. However, it never explicitly states when to prefer this over list/find alternatives or calls out exclusions, so the guidance remains implied rather than sharp.

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

• clockify_ensure_taskA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It transparently discloses the main side effect ('or creates it'), which is important, and adds the user-scoped config_root concern. However, it does not describe return behavior, exact-match/duplicate behavior, or failure cases, so the behavioral disclosure is only partial.

  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 focused sentences: the first explains behavior with a useful example, and the second provides configuration guidance. Every sentence adds value, and the main semantics are front-loaded.

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

  Completeness4/5

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

  The description plus a fully covered schema is sufficient to invoke the tool correctly: required params are clear, config_root usage is clarified, and the find-or-create semantics are stated. It would be stronger with return-shape or sibling-routing details, but nothing essential prevents correct 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 parameters are already well documented. The description adds some context about config_root usage, but it mostly reinforces the schema rather than adding significant new parameter meaning. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb phrase: 'Finds a task by name under a project or creates it', which precisely captures the ensure/find-or-create behavior. It also gives a concrete use case ('sync a GitHub label') and is clearly distinct from siblings like list_tasks or ensure_project because list_tasks only lists and ensure_project targets projects, not tasks.

  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 gives clear context for when the tool is relevant and specifically instructs when config_root is needed: 'when this MCP is user-scoped'. It does not explicitly name alternate tools or say when not to use it, so it stops short of a full 5.

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

• clockify_get_configA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates this is a read operation returning an 'effective' configuration, which implies merged/default behavior rather than raw file contents. However, it doesn't disclose what happens if the config file is missing, whether any parsing or fallback occurs, or whether there are any side effects; for a read-only getter, the main gaps are inconsequential but still unstated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences, concise and information-dense. The first sentence states what is returned and the second adds the exact config_root usage condition. No filler or repeated schema content from the description.

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

  Completeness4/5

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

  Given the tool is a simple one-parameter getter with no output schema and no annotations, the description covers the core domain (what config it returns, where it comes from, how to point at it). It is slightly light on defining how the configuration is represented when 'effective' merges sources, but for this complexity, the description is reasonably complete.

  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 input schema's description of `config_root` is already comprehensive—it defines the type, absolute git toplevel semantics, how to resolve it, reuse over calls, and what to avoid. The tool description adds the user-scoped tip but otherwise does not materially expand beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The verb 'Returns' is specific and the description names the exact resource: the effective `.clockify/config.yml` standards, including the four areas covered (per-method description, task, rounding, overlap, automation). This distinguishes the tool from all sibling Clockify tools, none of which read configuration.

  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 clearly explains when to pass `config_root` and how to determine it, including the required git toplevel semantics and the user-scoped caveat. There is no competing config tool among the siblings, so explicit 'use instead of' guidance is not necessary. However, it doesn't state scenarios where calling the tool might be unnecessary or where the config might be absent.

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

• clockify_get_running_timerA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses genuinely useful behaviors: the result is conditional ('if any'), the response includes an inactivity hint derived from .clockify/config.yml when configured, and the config_root parameter depends on the MCP's scoping mode. However, it does not explicitly state the operation is read-only, does not describe failure/error behavior, and leaves the return shape undefined. The description adds value beyond the name but does not fully cover the behavioral burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two tightly-packed sentences with zero filler. The first sentence front-loads the core purpose, and the second provides a single practical usage caveat. Every word earns its place, and it is appropriately sized for the tool's simplicity.

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

  Completeness4/5

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

  For a simple getter with two optional parameters and full schema coverage, the description covers the essentials: what is returned, the conditional empty result, and the config-related dependency. The one notable gap is that without an output schema, the description does not outline the structure of the returned timer object, which could cause some ambiguity for an agent trying to interpret the result. This is a minor gap given the overall clarity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, providing a strong baseline of 3. The description goes slightly further by clarifying the condition under which config_root should be supplied ('when this MCP is user-scoped'), linking the parameter to a runtime context that the schema alone does not fully address. The workspace_id parameter is not discussed in the description, but the schema's 'Workspace ID override.' is already adequate, so no compensation is required.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Returns'), a specific resource ('the currently running timer'), and a scope ('for the user, if any'). The 'if any' qualifier adds precision about the empty case, and the tool is clearly distinguishable from siblings like clockify_start_timer (mutation), clockify_stop_timer (mutation), and clockify_list_time_entries (historical list) by its read-only 'currently running' semantics.

  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?

  Usage context is implied rather than stated: an agent must infer to call this tool when it needs the current active timer. The description does provide a practical usage hint about when to pass config_root ('when this MCP is user-scoped'), but it offers no explicit when-not conditions or alternatives compared to clockify_list_time_entries or clockify_today_summary. The 'if any' phrasing does give a mild exclusionary signal (returns none when nothing is running).

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

• clockify_list_projectsA
  4/5.0
  Behavior3/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. The read-only nature is conveyed at least implicitly through the word 'lists,' and the user-scoped config nuance is useful. However, it remains silent on edge-case behavior such as what happens when no config or workspace is found, or whether the returned project list is paginated or limited.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

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

  Two sentences with zero filler, and the core purpose is front-loaded before the config_root caveat. The remaining sentence earns its place because it changes how an agent must supply parameters. This is appropriately concise.

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

  Completeness4/5

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

  For a low-complexity tool with zero required parameters and a thorough schema, the definition is sufficient to call the tool correctly. The remaining gaps are the lack of any output-schema/return-shape hint and the absence of sibling routing to clockify_ensure_project for the 'project not found' path — meaningful but not disqualifying.

  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 covers 100% of the 4 parameters with unusually rich descriptions — config_root explains the full resolution/caching strategy, and workspace_id documents its fallback order. The description barely needs to add anything, and its config_root note is consistent with the schema. This is the baseline case: schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Opens with a specific verb+resource phrase — 'Lists projects in a workspace' — which immediately isolates the tool from sibling listers like clockify_list_tasks and clockify_list_tags. The second sentence adds an explicit use case (mapping a git repo or task to a project). No tautology; the description is accurate and differentiating.

  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 gives a clear intended use: 'Use to map a git repo or task to a Clockify project,' and it gives conditional guidance about when to pass config_root (when this MCP is user-scoped). It does not explicitly name alternatives or exclusions — for instance, it never routes to clockify_ensure_project when the mapping target does not exist — so it stops short of the fullest guidance.

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

• clockify_create_time_entryA
  4.1/5.0
  Behavior4/5

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

  With no annotations at all, the description carries the disclosure burden. It reveals non-obvious behaviors: time rounding is disabled, entry_method selects manual vs automated config blocks, overlap handling requires a retry, and config_root depends on MCP scoping. It doesn't cover all possible side effects (e.g., auth, idempotency), but covers the main behavioral edge cases.

  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 five sentences are all high-signal: core behavior, time rounding behavior, parameter semantics, overlap retry logic, and a scoping caveat. No filler or repetition; the structure front-loads the primary action and flows to situational rules.

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

  Completeness4/5

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

  Given 14 parameters, no output schema, and no annotations, the description could never cover everything, but it does cover the non-obvious, high-risk aspects (overlap, config_root, rounding). It does not explain return format or error cases, which remain a gap, yet overall it is strong for a create-style tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 79%, so the schema already explains most parameters. The description adds value beyond the schema by explaining how entry_method interacts with description/overlap rules, what confirm_overlap is for, and when config_root matters. This goes beyond the baseline expected at 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 a specific verb+resource: 'Creates a completed time entry with explicit start and end.' It differentiates from 'start_timer' by emphasizing 'completed' and explicit time bounds, but does not name sibling tools or frame the distinction explicitly, so it lands between full differentiation and merely clear purpose.

  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 gives concrete guidance on when to retry with confirm_overlap ('When overlap.on_conflict is prompt, retry with confirm_overlap: true') and when config_root is needed. It lacks explicit when-not-to-use instructions or alternatives, but the context of creating a completed entry implies a usage scenario.

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

• clockify_stop_timerA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden, and it explicitly discloses config-driven behavior: honoring entry_method rounding (end only), include_seconds, and overlap.on_conflict. It could also state what happens when no timer is running, but the disclosed specifics are concrete and useful beyond the 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?

  Three front-loaded sentences with no filler: the main action first, followed by config-driven behavior and one environment-specific requirement. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple stop-action with fully documented parameters, this description plus schema is nearly complete. It lacks a note about the no-running-timer edge case and the expected return value, but those are minor given the clarity of the description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description adds inter-parameter meaning by tying entry_method to rounding-on-stop and overlap.conflict behavior. The config_root note also clarifies when this parameter is relevant for user-scoped MCP setups.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence uses a specific verb and resource ('Stops the currently running timer'), which clearly distinguishes it from siblings like clockify_start_timer and clockify_get_running_timer. This is not a vague restatement of the title.

  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 phrase 'currently running timer' provides clear context for when to invoke this tool. It does not explicitly name alternatives or when-not conditions, but the context is strong enough to qualify as 'clear context, no exclusions'.

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