Clockify MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific resource (client, project, tag, task, time_entry, report, user, workspace) and action (create, get, update, delete, duplicate, stop), making it easy for an agent to select the correct tool without confusion.
Naming Consistency5/5
Tool names follow a perfectly consistent verb_noun pattern throughout, such as create_client, get_clients, update_project, and delete_time_entry. This predictability enhances readability and usability for agents, with no deviations or mixed conventions.
Tool Count3/5
With 29 tools, the count is borderline high for a time tracking server, feeling somewhat heavy. While it covers many operations, it might be overwhelming for agents, though it's not extreme like 50+ tools.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for the Clockify domain, including clients, projects, tags, tasks, time entries, reports, users, and workspaces. There are no obvious gaps, and agents can handle all core workflows without dead ends.
Average 2.8/5 across 29 of 29 tools scored. Lowest: 2/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

Behavior1/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 but fails completely. It doesn't indicate whether this operation is reversible, what permissions are required, whether it's destructive (beyond the obvious implication of 'delete'), what happens to dependent resources, or what the response looks like. For a mutation tool with zero annotation coverage, this represents a critical gap in behavioral information.
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 maximally concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, though this brevity comes at the cost of completeness. Every word earns its place in conveying the basic purpose, even if insufficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what 'delete' means operationally, what confirmation might be needed, what data is returned (if any), error conditions, or system implications. Given the complexity of project deletion in what appears to be a project management system, this minimal description fails to provide necessary 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?
The description adds no parameter information beyond what's already in the schema, which has 100% coverage with clear descriptions for both workspaceId and projectId. The baseline score of 3 is appropriate since the schema adequately documents the parameters, though the description could have added context about parameter relationships or validation requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a project' is essentially a tautology that restates the tool name without adding meaningful context. While it clearly indicates a deletion action on a project resource, it doesn't specify what constitutes a 'project' in this system or differentiate this tool from other deletion tools like delete_client, delete_tag, delete_task, or delete_time_entry. The purpose is clear at a basic level but lacks the specificity needed for optimal agent understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project to exist first), consequences (e.g., what happens to associated tasks or time entries), or relationships to sibling tools like get_project or update_project. The agent receives no contextual information about appropriate usage scenarios.
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 states 'Create a new client', implying a write operation, but fails to describe any behavioral traits such as permissions needed, whether creation is idempotent, what happens on failure, or the expected response format. For a mutation tool with zero annotation coverage, this leaves critical gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately concise. However, it is front-loaded only in the sense that it states the action immediately, but lacks any follow-up context that could enhance usability. While structurally sound, its brevity contributes to under-specification rather than optimal clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It does not explain what a 'client' is, how it fits into the system, what data is returned upon creation, or any error conditions. For a tool that creates a new entity, more context is needed to guide an agent effectively, especially without structured support from annotations or 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%, with all parameters documented in the schema (workspaceId, name, archived). The description adds no additional meaning beyond what the schema provides, such as explaining the purpose of 'archived' or constraints on 'name'. However, since the schema fully covers parameter descriptions, the baseline score of 3 is appropriate, as the description does not need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new client' is a tautology that merely restates the tool name. It specifies the verb ('create') and resource ('client') but lacks any distinguishing details from sibling tools like 'create_project' or 'create_tag', which follow the same pattern. This minimal statement fails to clarify what a 'client' represents in this context or how it differs from other creatable entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention prerequisites (e.g., requiring a workspaceId), exclusions, or comparisons to sibling tools like 'update_client' or 'get_clients'. Without any context, an agent must infer usage solely from the name and schema, which is insufficient for effective tool selection.
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 but only states the action ('create') without details on permissions, side effects, or response format. It fails to address critical aspects like whether creation is idempotent, what happens on duplicate names, or error conditions, which are essential 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 a single sentence ('Create a new tag'), which is front-loaded and wastes no words. While it lacks detail, it efficiently communicates the core action without redundancy or unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete. It does not compensate for the lack of structured data by explaining behavioral traits, return values, or error handling, leaving significant gaps for agent invocation.
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 three parameters (workspaceId, name, archived). The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints, but 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new tag' is a tautology that merely restates the tool name without adding specificity. It identifies the verb ('create') and resource ('tag') but lacks differentiation from sibling tools like 'create_client' or 'create_project', failing to explain what makes a tag distinct in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a workspace), exclusions, or comparisons to sibling tools like 'update_tag' or 'get_tags', leaving the agent without context for selection.
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. 'Delete a task' implies a destructive mutation, but it doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects. This is inadequate for a destructive operation 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 just three words, front-loading the core action. There's no wasted language, though this conciseness comes at the cost of completeness.
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 destructive deletion tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what happens after deletion, whether there are confirmation steps, error conditions, or how it fits within the broader task management 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 fully documents the three required parameters (workspaceId, projectId, taskId). The description adds no parameter semantics beyond what the schema provides, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a task' is a tautology that restates the tool name without adding meaningful context. While it includes the verb 'delete' and resource 'task', it lacks specificity about what deletion entails or how it differs from other deletion tools like delete_project or delete_time_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when deletion is appropriate, or how it relates to sibling tools like delete_project or delete_time_entry, leaving the agent with no usage 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?
No annotations are provided, so the description carries full burden. 'Create a new project' implies a write/mutation operation but doesn't disclose behavioral traits like required permissions, whether creation is idempotent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical 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 a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, though this conciseness comes at the cost of detail. Every word earns its place in conveying the core action.
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 7 parameters (including nested objects), no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation, what values are returned, or important behavioral context. The agent lacks sufficient information to understand the full implications of using this tool.
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 parameters are well-documented in the schema. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 'Create a new project' states the verb and resource but is vague about what constitutes a project in this context. It distinguishes from deletion siblings but not clearly from other creation tools like create_client or create_task. The purpose is understandable but lacks specificity about what a 'project' represents in this system.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or comparisons with sibling tools like create_task or update_project. The agent must infer usage from the tool name alone, which is insufficient for informed selection.
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. 'Delete a client' implies a destructive, irreversible mutation, but it doesn't specify consequences (e.g., whether associated data like projects or time entries are also deleted), permissions required, error conditions (e.g., if the client doesn't exist), or response format. This leaves critical gaps for safe and effective use.
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 three words, with no wasted language. It's front-loaded with the core action, making it easy to scan. Every word earns its place by directly conveying the tool's purpose without 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 the complexity of a destructive deletion tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral outcomes, error handling, and return values, which are crucial for an agent to use this tool correctly and safely. The high schema coverage doesn't compensate for these gaps in a mutation 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?
The input schema has 100% description coverage, with clear documentation for workspaceId and clientId. The description adds no parameter-specific information beyond what the schema provides, such as format examples or relationships between parameters. With high schema coverage, the baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a client' clearly states the verb ('Delete') and resource ('a client'), making the basic purpose understandable. However, it doesn't differentiate from sibling deletion tools like delete_project, delete_tag, delete_task, or delete_time_entry, nor does it specify what constitutes a 'client' in this context beyond what the tool name implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a client to exist), exclusions (e.g., not for archived clients), or comparisons with related tools like update_client or get_clients. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete a tag' implies a destructive mutation, but it doesn't specify whether this requires specific permissions, whether the deletion is permanent or reversible, what happens to associated resources (like tasks or projects that might reference the tag), or any rate limits. For a destructive operation with zero annotation coverage, this is a significant gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with just three words that directly state the tool's function. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of detail, the description is perfectly structured for what it attempts to communicate.
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 operation (delete) with no annotations, no output schema, and a description that provides minimal context, the description is incomplete. It doesn't address the implications of deletion, error conditions, authentication requirements, or what constitutes a 'tag' in this system. For a mutation tool in a system with multiple resource types, more context would be needed 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?
The input schema has 100% description coverage, with both parameters (workspaceId and tagId) clearly documented in the schema itself. The description doesn't add any meaning beyond what the schema already provides - it doesn't explain how to obtain these IDs, their format, or relationships between them. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 'Delete a tag' clearly states the action (delete) and resource (tag), making the basic purpose understandable. However, it doesn't differentiate this tool from other delete operations in the sibling list (like delete_client, delete_project, delete_task, delete_time_entry) beyond specifying the resource type. It's a straightforward but generic description that doesn't provide context about what 'tag' means in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools including 'delete_task', 'delete_project', and 'update_tag', there's no indication of whether this is for removing metadata tags, categorization tags, or something else. The description doesn't mention prerequisites, consequences, or when this operation would be appropriate versus updating a tag instead.
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 states it 'generates' a report without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires specific permissions, rate limits, side effects, or what the output looks like (e.g., file download vs. data return). For a tool with 17 parameters and no annotations, this is a significant gap.
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's front-loaded with the core purpose and appropriately sized for a tool where parameter details are handled in the schema. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the output format (e.g., whether it returns data or triggers a file download), behavioral constraints, or how it differs from sibling reporting tools. For a detailed reporting tool with many filters and export options, more context is needed.
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 17 parameters thoroughly with descriptions, enums, and defaults. The description adds no additional parameter semantics beyond implying it's for time tracking reports, which is already clear from parameter names like 'dateRangeStart'. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate a detailed time tracking report' clearly states the action (generate) and resource (time tracking report), but lacks specificity about what makes it 'detailed' compared to sibling tools like 'get_summary_report' or 'get_time_entries'. It distinguishes itself from creation/deletion tools but not clearly from 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 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 like 'get_summary_report' or 'get_time_entries'. The description implies it's for generating reports but doesn't specify scenarios, prerequisites, or exclusions. Sibling tools include other reporting options, but no comparison is offered.
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 but offers minimal information. 'Generate' implies a read operation that creates output, but there's no mention of permissions required, rate limits, whether the operation is idempotent, what happens with large date ranges, or the nature of the generated output. For a 13-parameter tool with no annotation coverage, this represents a significant behavioral transparency gap.
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 wasted words. It's appropriately sized for what it communicates and front-loads the essential information. Every word earns its place, making this an excellent example of conciseness despite the overall descriptive shortcomings.
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 (13 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what a 'summary' report contains versus a 'detailed' report, doesn't mention output format implications (despite the exportType parameter), and provides no behavioral context. For a reporting tool with extensive filtering capabilities, the description should do more to help an agent understand when and how to use it effectively.
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 has 100% description coverage, providing clear documentation for all 13 parameters. The description adds no parameter-specific information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description. The description doesn't compensate but doesn't need to given the comprehensive schema.
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 'Generate a summary time tracking report' clearly states the verb ('generate') and resource ('summary time tracking report'), making the purpose understandable. However, it doesn't distinguish this tool from sibling 'get_detailed_report' - both appear to generate reports, so the distinction between 'summary' and 'detailed' isn't explained. This makes it adequate but with clear gaps in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With sibling tools like 'get_detailed_report' and 'get_time_entries' available, there's no indication of when a summary report is preferable to a detailed report or raw time entries. The description lacks any context about appropriate use cases, 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 the full burden of behavioral disclosure. While 'update' implies mutation, it doesn't specify required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. This is inadequate 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.
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 8 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, leaving significant gaps for an AI agent to understand the tool's full implications.
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 has 100% description coverage, so parameters like workspaceId, projectId, name, etc., are well-documented in the schema. The description adds no additional meaning beyond the schema, but the baseline is 3 when schema coverage is high, even without param info in the description.
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 'Update an existing project' clearly states the action (update) and resource (project), but it's vague about what aspects can be updated and doesn't distinguish this tool from sibling tools like update_client or update_task. It provides minimal differentiation beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_client or update_task, nor does it mention prerequisites such as needing an existing project ID. There's no explicit when/when-not context or comparison to 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 the full burden of behavioral disclosure. 'Update an existing tag' implies a mutation operation, but it doesn't disclose any behavioral traits such as required permissions, whether changes are reversible, rate limits, error conditions, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
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—'Update an existing tag' is front-loaded and appropriately sized for the tool's purpose. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 4 parameters, no annotations, and no output schema), the description is incomplete. It lacks information on behavioral aspects, usage context, and expected outcomes. For a tool that modifies data, more detail is needed to ensure safe and correct 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 all four parameters (workspaceId, tagId, name, archived) with clear descriptions. The description adds no meaning beyond what the schema provides—it doesn't explain parameter interactions, defaults, or examples. 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 'Update an existing tag' clearly states the action (update) and resource (tag), but it's vague about what specifically gets updated. It distinguishes from sibling tools like 'create_tag' and 'delete_tag' by specifying 'existing', but doesn't differentiate from other update tools (e.g., update_client, update_project) 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing workspaceId and tagId), when not to use it (e.g., for creating new tags), or how it relates to sibling tools like 'get_tags' for retrieving tags first. Usage is implied by the name but not explicitly 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?
No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but the description doesn't disclose behavioral traits like required permissions, whether the task is immediately active, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, this is inadequate.
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's front-loaded with the core action and resource. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. For a 6-parameter tool that creates resources, more context is needed to guide 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%, providing good documentation for all parameters. The description adds no parameter-specific information beyond implying a project context. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantics like format examples or constraints not in 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 'Create a new task in a project' clearly states the action (create) and resource (task) with context (in a project). It distinguishes from siblings like create_project or create_time_entry by specifying the resource type. However, it doesn't explicitly differentiate from create_tag or create_client beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a project first), when not to use it, or how it relates to sibling tools like update_task or get_tasks. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new time entry' implies a write/mutation operation, but doesn't disclose authentication requirements, rate limits, whether entries can overlap, what happens if end time is omitted, or the response format. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 states the core purpose without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation. Every word earns its place by clearly communicating the primary action.
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 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a valid time entry, how the system handles optional vs required fields, what happens on success/failure, or how this tool relates to other time management tools in the sibling list. The agent lacks crucial context for proper 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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have explained relationships between parameters (like how projectId relates to workspaceId).
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 like 'update_time_entry' or 'duplicate_time_entry' by specifying it creates a new entry rather than modifying or copying existing ones. However, it doesn't specify what a 'time entry' represents in this system's context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing workspace access), when to use 'create_time_entry' versus 'duplicate_time_entry' or 'stop_time_entry', or any constraints on creating entries. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but it doesn't specify whether deletion is permanent/reversible, what permissions are required, or what happens to associated data. 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 wasted words. It's appropriately sized for a simple delete operation and front-loads the core action.
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 destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain the mutation's impact, success/failure behavior, or error conditions, leaving critical gaps for agent decision-making.
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 parameters are fully documented in the schema. The description adds no additional meaning about workspaceId or timeEntryId beyond what the schema provides, 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 ('Delete') and resource ('a time entry'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like delete_client or delete_task, which follow the same pattern 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing time entry), related operations (e.g., update_time_entry for modifications), or constraints (e.g., cannot delete running entries).
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. 'Duplicate' implies a mutation operation, but the description doesn't specify whether this creates a new time entry with copied data, if it requires specific permissions, what happens to the original entry, or what the response looks like. This is a significant gap 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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, immediately conveying the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, output, error conditions, or how it fits within the context of sibling tools. The 100% schema coverage helps with parameters, but overall completeness is inadequate for this type of operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters (workspaceId, userId, id) documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as explaining relationships between parameters or usage nuances. With high schema coverage, the baseline is 3.
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 'Duplicate a time entry' clearly states the verb ('duplicate') and resource ('time entry'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_time_entry' or 'update_time_entry' that also manipulate time entries, which would require a 5.
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. There's no mention of prerequisites (e.g., needing an existing time entry), when duplication is appropriate compared to creating a new entry, or how it differs from sibling tools like 'create_time_entry' or 'update_time_entry'.
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 retrieving 'all clients' but doesn't clarify if this includes archived clients by default, how pagination works with the page/pageSize parameters, or what the response format looks like. This leaves significant gaps for a tool with 5 parameters.
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 gets straight to the point without unnecessary words. It's perfectly front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the filtering behavior (archived/name), pagination details, or what the return data looks like. 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?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any meaningful information about parameters beyond implying workspace context, which the schema already covers with workspaceId. 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 ('Get') and resource ('all clients in a workspace'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_workspace_users' or 'get_projects' that also retrieve workspace-related data, 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 like 'get_workspace_users' or 'get_projects', nor does it mention prerequisites such as needing workspace access. It only states what the tool does, not when it's appropriate.
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. 'Get' implies a read-only operation, but it doesn't disclose behavioral traits such as error handling (e.g., what happens if IDs are invalid), response format, or whether it requires specific permissions. The description is minimal and lacks necessary context for safe invocation.
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 without unnecessary words. Every part of the sentence ('Get a specific project by ID') contributes directly to understanding the tool's function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 2 required parameters. It doesn't explain what 'get' returns (e.g., project details, status), error conditions, or authentication needs. For a read operation in a system with multiple similar tools, more context is needed to ensure correct 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%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond implying 'projectId' identifies the specific project and 'workspaceId' provides context. It doesn't explain parameter relationships or format expectations, 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 action ('Get') and resource ('a specific project by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_projects' (plural) by specifying retrieval of a single project. However, it doesn't explicitly mention what 'get' entails (e.g., retrieving metadata/details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_project' over 'get_projects' or other retrieval tools, nor does it specify prerequisites like authentication or workspace context needed before use.
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 states 'Get all projects' but doesn't clarify if this is a read-only operation, whether it requires specific permissions, how pagination works (implied by page/pageSize parameters), or what the output format is. This leaves significant gaps for a tool with 12 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain the return values, pagination behavior, or error conditions, leaving the agent with incomplete information to use the tool effectively in a real-world 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?
The description mentions 'in a workspace,' which aligns with the required workspaceId parameter, but adds no further semantic context beyond what the schema provides. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters thoroughly, and the description doesn't compensate with additional insights like default behaviors or filtering logic.
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 ('Get') and resource ('projects in a workspace'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_project' (singular), which appears to fetch a single project rather than all projects, missing an opportunity for explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_project' for single projects or 'get_detailed_report' for more comprehensive data, nor does it specify prerequisites or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' tags, implying a read operation, but doesn't cover pagination behavior, rate limits, permissions needed, or what 'all tags' entails (e.g., default ordering). This leaves significant gaps for a tool with 5 parameters.
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 without unnecessary words. It's appropriately sized for a straightforward tool, with no wasted verbiage.
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 inadequate. It lacks details on behavior, output format, error handling, or usage context, making it incomplete for effective agent operation despite the clear 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?
The schema description coverage is 100%, so parameters like 'workspaceId', 'archived', and 'page' are well-documented in the schema. The description adds no additional meaning beyond implying filtering via 'all tags', which aligns with the schema but doesn't compensate for or enhance it.
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 ('Get') and resource ('all tags in a workspace'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_clients' or 'get_tasks' beyond the resource name, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare it to other 'get_' tools in the list, leaving the agent without context for selection.
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. 'Get all tasks' implies a read operation, but doesn't disclose pagination behavior (implied by page/pageSize parameters but not described), rate limits, authentication needs, whether it returns archived/inactive tasks by default, or what the response format looks like. The description is minimal and lacks behavioral context 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward list operation and front-loads the core purpose immediately.
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 tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the filtering logic (how isActive and name interact), pagination behavior, response format, or error conditions. The agent would need to infer much from the parameter schema alone, which is insufficient for confident tool invocation.
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 6 parameters. The description adds no additional parameter information beyond what's in the schema. It mentions 'all tasks in a project' which aligns with required parameters workspaceId and projectId, but provides no extra semantic context about filtering logic or parameter interactions.
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 'Get all tasks in a project' clearly states the action (get) and resource (tasks), with scope (in a project). It distinguishes from sibling tools like 'get_task' (singular) and 'get_time_entries', but doesn't explicitly differentiate from other list operations like 'get_clients' or 'get_tags' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_tasks' versus 'get_task' (singular), 'get_time_entries' (which might include task information), or other filtering/list tools. No prerequisites, exclusions, or comparative context 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 the full burden of behavioral disclosure but only states the basic action. It doesn't cover critical aspects like pagination behavior (implied by 'page' and 'pageSize' parameters), authentication needs, rate limits, or what 'hydrated' data includes, making it insufficient for a mutation-free tool with many parameters.
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's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, earning full marks for conciseness.
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 (15 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on return format, error handling, or behavioral traits like pagination, which are crucial for an agent to use this tool effectively in a real-world 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?
The schema description coverage is 100%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond the schema, such as explaining filter interactions or default behaviors. This meets the baseline of 3 since 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 for a user'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_detailed_report' or 'get_summary_report' that also retrieve time-related data, 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. It doesn't mention siblings like 'get_detailed_report' for aggregated data or 'get_summary_report' for summaries, nor does it specify prerequisites or exclusions, leaving the agent without usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get') but lacks details on permissions, rate limits, pagination, or response format. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves and what to expect from its execution.
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 without unnecessary words. Every part earns its place by directly conveying the tool's function, making it easy to parse and understand quickly. It avoids redundancy and stays focused on the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of users. It doesn't explain what data is returned, how results are structured, or any limitations (e.g., max users per call). For a read operation with no structured support, more contextual details are needed to guide 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?
The description implies a 'workspaceId' parameter by mentioning 'in a workspace', but doesn't add meaning beyond the schema's 100% coverage. The schema already documents the single required parameter with a clear description. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with extra details like format examples or constraints.
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 ('all users in a workspace'), making the purpose immediately understandable. It distinguishes from siblings like 'get_current_user' (individual) and 'get_workspaces' (different resource), though it doesn't explicitly contrast with them. The specificity is good but could be slightly enhanced for full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a workspace ID), exclusions, or comparisons to similar tools like 'get_clients' or 'get_current_user'. Without such context, the agent must infer usage from the name alone, which is insufficient for optimal tool selection.
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 offers minimal behavioral insight. It implies a mutation (stopping changes state) but doesn't disclose permissions needed, side effects (e.g., does it trigger notifications?), error conditions, or what happens if no running entry exists. The description adds no context 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without fluff.
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 no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or error handling, nor does it hint at return values. Given the complexity of stopping a time entry (which likely involves state changes and validation), more context is needed 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 parameters are fully documented in the schema. The description adds no additional meaning about parameters—it doesn't explain why workspaceId and userId are required, how they relate to stopping, or the implications of the optional 'end' parameter. 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 action ('Stop') and resource ('a running time entry'), making the purpose immediately understandable. It distinguishes from siblings like 'create_time_entry' or 'update_time_entry' by focusing on stopping rather than creating or modifying. However, it doesn't specify what constitutes a 'running' time entry versus other states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a time entry must be running first), exclusions, or relationships with sibling tools like 'update_time_entry' or 'duplicate_time_entry'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't address permissions needed, whether changes are reversible, what happens to unspecified fields, or potential side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward update operation and front-loads the essential information immediately.
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 no annotations and no output schema, the description is inadequate. It doesn't explain what fields can be updated beyond the schema, what the response looks like, or important behavioral aspects. Given the complexity of client updates and lack of structured coverage, more descriptive context is needed.
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. The description doesn't add any parameter-specific context beyond what's in the schema (e.g., explaining relationships between parameters or special constraints). The baseline of 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 ('update') and resource ('an existing client'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_project' or 'update_tag' beyond the resource name, missing explicit distinction between different update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_client' or 'delete_client'. It doesn't mention prerequisites (e.g., needing an existing client ID) or contextual factors that would inform tool selection among the many update operations available.
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. 'Update an existing task' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a 7-parameter mutation tool, 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 maximally concise - a single clear sentence with zero wasted words. It's front-loaded with the essential action and resource, making it immediately scannable and understandable.
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 and no annotations or output schema, the description is insufficient. It doesn't address what fields can be updated, what the update operation returns, error handling, or how it relates to other task operations (get_task, delete_task, create_task). The context demands more completeness for a tool that modifies 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?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema properties. This meets the baseline expectation when schema coverage is complete.
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 ('an existing task'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_' tools (like update_project, update_tag, etc.), which all follow the same pattern of updating 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 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. There's no mention of prerequisites (like needing workspace/project/task IDs), when not to use it, or how it differs from other update operations in the sibling tool list.
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 'update' implying mutation but doesn't cover permissions, side effects, error handling, or response format. This is inadequate 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it highly concise 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?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It lacks behavioral context, usage guidance, and any explanation of return values or error conditions, leaving significant gaps for agent 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 fully documents all 9 parameters. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does all the 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 ('update') and resource ('existing time entry'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'duplicate_time_entry' or specify what aspects of a time entry can be updated, 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?
No guidance is provided on when to use this tool versus alternatives like 'create_time_entry', 'duplicate_time_entry', or 'delete_time_entry'. The description lacks context about prerequisites, timing, or any constraints, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention authentication needs, rate limits, error conditions, or what happens if the task doesn't exist. For a tool with three required parameters and no annotation coverage, this leaves significant behavioral 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 a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Get' (action), 'specific task' (resource), 'by ID' (method). There's no redundancy or unnecessary elaboration.
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 read operation with three required parameters and no output schema, the description is minimally adequate. It states what the tool does but lacks context about authentication, error handling, return format, or relationships to other tools. The high schema coverage helps, but behavioral context is incomplete given the parameter complexity.
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%, with all three parameters clearly documented in the schema. The description adds no parameter-specific information beyond implying 'taskId' is the primary identifier. This meets the baseline of 3 when schema coverage is high, but doesn't provide additional context like parameter relationships or format 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 'Get a specific task by ID' clearly states the verb ('Get') and resource ('task'), and specifies the lookup method ('by ID'). It distinguishes from siblings like 'get_tasks' (plural) by emphasizing retrieval of a single specific task. However, it doesn't explicitly contrast with 'get_project' or 'update_task' which might be relevant alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing workspace/project context), contrast with 'get_tasks' for listing multiple tasks, or indicate when 'update_task' or 'delete_task' might be more appropriate. Usage is implied but not explicitly 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 retrieval ('Get all workspaces') but doesn't specify whether this requires authentication, how results are returned (e.g., pagination, format), or any rate limits. The description is minimal and lacks critical operational details.
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, clear sentence with no wasted words. It front-loads the essential information ('Get all workspaces for the current user'), making it highly efficient and easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what a 'workspace' entails in this context, how the data is structured in response, or any error conditions. For a retrieval tool, more context on output behavior is needed despite the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for this scenario is 4, as it avoids unnecessary detail while matching the schema's simplicity.
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 ('Get') and resource ('all workspaces for the current user'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_projects' or 'get_clients', but the specificity of 'workspaces' and 'current user' provides adequate distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_projects' or 'get_workspace_users'. It states what the tool does but offers no context about prerequisites, timing, or comparison to other retrieval tools in the sibling list.
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 states this is a read operation ('Get'), implying it's non-destructive, but doesn't specify authentication requirements, rate limits, error conditions, or what 'information' includes (e.g., basic vs. detailed data). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, clear sentence with zero waste—it directly states the tool's purpose without fluff. It's front-loaded and appropriately sized for a simple tool with no parameters, making it easy to parse quickly.
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 minimally adequate. It explains what the tool does but lacks details on return values, authentication, or differentiation from siblings. Without an output schema, the description should ideally hint at what 'information' includes, but it doesn't, leaving some context gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description doesn't mention any parameters, which is appropriate and adds no unnecessary information. Since there are no parameters to explain, this meets the baseline expectation without compensation 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 ('Get') and resource ('information about the current user'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its siblings (like get_workspace_users or get_clients), which also retrieve user-related data but with different scopes. The description is specific enough to understand what it does but 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 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. Given the sibling tools include get_workspace_users (which might list multiple users) and other get_* tools for specific resources, there's no indication whether this tool is for authentication context, profile details, or a limited subset of user data. 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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